주요 RDBMS 성능 비교

1. 서론: 주요 RDBMS 성능 지형도

1.1 분석의 필요성 및 목적

현대 디지털 비즈니스 환경에서 데이터베이스의 성능은 더 이상 단순한 응답 속도의 문제가 아니다. 이는 시스템 전체의 안정성, 비즈니스 연속성을 보장하는 확장성, 그리고 장기적인 운영 효율성을 좌우하는 총 소유 비용(TCO)까지 포괄하는 다차원적인 개념으로 진화하였다. 애플리케이션의 워크로드, 데이터의 규모와 복잡성, 그리고 비즈니스의 성장 전략에 따라 최적의 관계형 데이터베이스 관리 시스템(RDBMS)은 달라질 수밖에 없다. 따라서 기술 리더는 각 RDBMS의 근본적인 아키텍처와 그로 인해 발현되는 성능 특성을 심층적으로 이해하고, 이를 바탕으로 전략적인 의사결정을 내려야 하는 중대한 과제에 직면해 있다.

본 보고서는 현재 시장을 주도하고 있는 5대 RDBMS, 즉 Oracle, Microsoft SQL Server, PostgreSQL, MySQL, MariaDB를 분석 대상으로 삼는다. 분석의 목적은 이들 시스템의 성능을 단편적인 벤치마크 수치로 비교하는 것을 넘어, 성능의 근간이 되는 핵심 아키텍처, 트랜잭션 처리의 핵심인 동시성 제어 메커니즘, 데이터 접근 패턴을 좌우하는 인덱싱 전략, 무중단 서비스를 위한 확장성 및 고가용성 솔루션, 그리고 실증적인 벤치마크 데이터와 총 소유 비용에 이르기까지 다각적인 관점에서 심층 비교 분석하는 데 있다. 이를 통해 특정 워크로드와 비즈니스 요구사항에 가장 적합한 RDBMS를 선택하고, 장기적인 데이터 아키텍처 전략을 수립하는 데 필요한 깊이 있는 기술적 통찰력을 제공하고자 한다.

1.2 분석 대상 RDBMS 개요

본 보고서에서 다루는 5개의 RDBMS는 각각 뚜렷한 역사적 배경과 시장에서의 입지를 가지고 있으며, 이는 각 시스템의 기술적 특성과 발전 방향에 지대한 영향을 미쳤다.

• Oracle Database: 엔터프라이즈 RDBMS 시장의 오랜 지배자로서, 최고의 안정성, 강력한 기능 세트, 그리고 검증된 확장성을 무기로 금융, 통신, 공공 등 미션 크리티컬(Mission-Critical) 시스템에서 절대적인 신뢰를 받고 있다.1 고가용성을 위한 RAC(Real Application Clusters)와 같은 독보적인 기술을 통해 시장을 선도한다.
• Microsoft SQL Server: Microsoft의 강력한 기업 생태계와 긴밀하게 통합되어, 특히 Windows 환경을 사용하는 기업들에게 높은 인기를 구가한다. 직관적인 관리 도구, 우수한 비즈니스 인텔리전스(BI) 및 분석 기능, 그리고 Azure 클라우드와의 완벽한 연동을 강점으로 내세운다.4
• PostgreSQL: “세상에서 가장 진보한 오픈소스 RDBMS“라는 별칭에 걸맞게, 엄격한 SQL 표준 준수, 뛰어난 확장성(사용자 정의 데이터 타입, 함수, 연산자 등), 그리고 복잡한 쿼리를 안정적으로 처리하는 능력으로 명성이 높다. 최근 몇 년간 가장 빠르게 영향력을 확대하며 상용 RDBMS의 강력한 대안으로 부상하고 있다.6
• MySQL: LAMP (Linux, Apache, MySQL, PHP) 스택의 핵심 구성원으로서 웹 애플리케이션 개발 시장의 사실상 표준으로 자리 잡았다. 단순한 구조, 빠른 읽기 성능, 그리고 세계에서 가장 거대한 개발자 커뮤니티와 풍부한 자료를 바탕으로 스타트업부터 대규모 웹 서비스에 이르기까지 폭넓게 사용된다.6
• MariaDB: MySQL이 Oracle에 인수된 이후, MySQL의 원개발자들이 주축이 되어 시작한 커뮤니티 기반의 포크(fork) 프로젝트다. MySQL과의 높은 호환성을 유지하면서도, 성능 개선을 위한 독자적인 개발 노선을 걷고 있다. 특히 ColumnStore와 같은 분석용 스토리지 엔진을 통합하며 트랜잭션 처리와 분석을 동시에 지원하는 방향으로 진화하고 있다.11

1.3 성능 비교를 위한 다차원적 프레임워크 제시

성능에 대한 단일하고 절대적인 척도는 존재하지 않는다. 따라서 본 보고서는 RDBMS의 성능을 종합적으로 평가하기 위해 다음과 같은 7가지 핵심적인 기술 및 비즈니스 관점으로 구성된 다차원적 프레임워크를 적용하여 분석을 진행한다.

1. 핵심 아키텍처 (Core Architecture): 메모리, 프로세스/스레드, 스토리지 구조 등 시스템의 근간을 이루는 설계 사상이 성능에 미치는 영향을 분석한다.
2. 동시성 제어 메커니즘 (Concurrency Control): 다중 사용자 환경에서의 트랜잭션 처리 효율성을 결정하는 MVCC 구현 방식과 잠금 전략을 비교한다.
3. 인덱싱 전략 (Indexing Strategies): B-Tree, Bitmap, Columnstore 등 다양한 인덱스 유형이 특정 워크로드(OLTP/OLAP)의 성능을 어떻게 최적화하는지 탐구한다.
4. 확장성 및 고가용성 (Scalability & High Availability): 서비스 중단 없이 증가하는 부하를 처리하고 장애에 대응하는 클러스터링 및 복제 기술을 분석한다.
5. 쿼리 처리 및 최적화 (Query Processing & Optimization): SQL 파싱부터 실행 계획 수립, 실행에 이르는 과정에서 옵티마이저의 역할과 성능 차이를 고찰한다.
6. 벤치마크 기반 실증 성능 (Benchmark-based Empirical Performance): TPC-C(OLTP)와 TPC-H(OLAP) 등 산업 표준 벤치마크 결과를 통해 각 RDBMS의 실증적 성능 특성을 검증한다.
7. 총 소유 비용 및 라이선스 (Total Cost of Ownership & Licensing): 라이선스 모델, 지원 비용, 인력 및 생태계 요소를 포함하여 성능 대비 비용 효율성을 평가한다.

이러한 프레임워크를 통해 각 RDBMS의 강점과 약점을 명확히 하고, 최종적으로는 특정 비즈니스 시나리오에 가장 부합하는 최적의 솔루션을 도출하기 위한 견고한 기반을 마련할 것이다.

2. 핵심 아키텍처 비교 분석: 성능의 근간

데이터베이스의 성능은 그 근간을 이루는 아키텍처 설계에 의해 결정된다. 메모리, 프로세스, 스토리지라는 세 가지 핵심 축이 어떻게 구성되고 상호작용하는지에 따라 RDBMS의 기본적인 성능 특성과 한계가 규정된다. 각 RDBMS는 고유한 역사적 배경과 기술적 철학을 바탕으로 서로 다른 아키텍처를 발전시켜왔다.

2.1 메모리 구조

메모리는 디스크 I/O의 병목을 완화하고 데이터 처리 속도를 극대화하는 가장 중요한 자원이다. 각 RDBMS는 메모리를 관리하고 활용하는 방식에서 뚜렷한 차이를 보인다.

• Oracle: Oracle의 메모리 아키텍처는 공유 메모리 영역인 **SGA(System Global Area)**와 각 사용자 세션을 위한 개별 메모리 영역인 **PGA(Program Global Area)**로 명확하게 분리되는 정교한 구조를 특징으로 한다.14 SGA는 여러 프로세스가 공유하는 핵심 영역으로, 디스크에서 읽어온 데이터 블록을 캐시하는 데이터베이스 버퍼 캐시(Database Buffer Cache), 파싱된 SQL 문장과 실행 계획을 저장하여 재사용하는 공유 풀(Shared Pool), 그리고 데이터 변경 사항을 디스크에 기록하기 전에 임시 저장하는 리두 로그 버퍼(Redo Log Buffer) 등으로 구성된다.16 이 구조는 대규모 동시 사용자 환경에서 각 컴포넌트의 크기를 세밀하게 조정하는 정교한 튜닝을 통해 최고의 성능을 이끌어낼 수 있도록 설계되었다. 특히, Oracle은 SSD와 같은 플래시 메모리를 버퍼 캐시의 확장 영역으로 사용하는 Database Smart Flash Cache 기능을 제공하여, 물리적 RAM의 한계를 넘어 I/O 성능을 극대화하는 엔터프라이즈급 솔루션을 제시한다.14
• MS SQL Server: SQL Server는 통합된 버퍼 풀(Unified Buffer Pool) 아키텍처를 채택하고 있다.17 이는 데이터 페이지, 실행 계획 캐시, 프로시저 캐시 등 다양한 유형의 캐시를 별도로 분리하지 않고 단일한 메모리 공간에서 동적으로 관리하는 방식이다. 이 접근법은 메모리 관리를 단순화하고, 운영체제(주로 Windows)의 메모리 관리자와 긴밀하게 통합되어 자원 할당의 효율성을 높인다.4 Oracle의 복잡하고 세분화된 구조에 비해 관리자의 개입을 최소화하는 장점이 있지만, 특정 워크로드에 대한 극단적인 메모리 튜닝의 유연성은 상대적으로 제한될 수 있다.
• PostgreSQL: PostgreSQL은 여러 백엔드 프로세스들이 공유하는 공유 메모리(Shared Memory) 영역을 중심으로 동작한다. 이 영역에는 디스크 블록을 캐시하는 **공유 버퍼(Shared Buffers)**와 트랜잭션 로그를 임시 저장하는 WAL(Write-Ahead Log) 버퍼 등이 포함된다.7 PostgreSQL 아키텍처의 특징은 각 클라이언트 연결마다 별도의 백엔드 프로세스가 생성되고, 이 프로세스는 정렬(sorting)이나 해시 조인(hash join)과 같은 복잡한 작업을 수행하기 위해 **작업 메모리(work_mem)**라는 자신만의 전용 메모리 공간을 할당받는다는 점이다.8 이는 프로세스 수준의 강력한 격리를 통해 안정성을 높이는 데 기여한다.
• MySQL/MariaDB: MySQL과 MariaDB의 아키텍처에서 가장 두드러진 특징은 플러그형 스토리지 엔진(Pluggable Storage Engine) 구조이며, 메모리 관리 방식 또한 주로 사용하는 스토리지 엔진에 의해 결정된다.9 현재 사실상의 표준인 InnoDB(MariaDB에서는 XtraDB) 스토리지 엔진의 경우, InnoDB 버퍼 풀이 가장 핵심적인 메모리 영역이다. 이 버퍼 풀은 데이터와 인덱스를 모두 메모리에 캐시하여 디스크 I/O를 최소화하는 역할을 한다.11 이 외에도 과거 버전에서 중요했던 쿼리 결과를 텍스트 그대로 캐시하는 쿼리 캐시(Query Cache)(최신 버전에서는 성능 문제로 인해 비활성화되거나 제거됨)와 각 연결 스레드별로 할당되는 소규모 버퍼들이 존재한다.9

2.2 프로세스 및 스레드 모델

동시 접속 클라이언트의 요청을 어떻게 처리하는지는 RDBMS의 확장성과 자원 효율성을 결정하는 핵심 요소다.

• Oracle & PostgreSQL (프로세스 기반 모델): 이 두 시스템은 전통적으로 클라이언트 연결마다 운영체제의 새로운 프로세스를 생성(fork)하는 프로세스 기반 모델을 사용한다.20 이 방식의 가장 큰 장점은 안정성이다. 각 프로세스는 독립적인 메모리 공간을 가지므로, 하나의 클라이언트 연결을 처리하는 프로세스에서 오류가 발생하더라도 다른 프로세스나 전체 데이터베이스 시스템에 영향을 미치지 않는다. 하지만 수천 개 이상의 많은 동시 연결이 발생하는 환경에서는 프로세스 생성 및 컨텍스트 스위칭에 따른 오버헤드가 커지고, 각 프로세스가 차지하는 메모리 총량이 시스템의 한계에 도달할 수 있다. 이러한 단점을 보완하기 위해 Oracle은 다수의 클라이언트 연결을 소수의 서버 프로세스 풀이 공유하여 처리하는 공유 서버(Shared Server) 아키텍처를 옵션으로 제공한다.23
• MS SQL Server & MySQL/MariaDB (스레드 기반 모델): 이 시스템들은 단일 데이터베이스 프로세스 내에서 각 클라이언트 연결에 대해 경량화된 실행 단위인 **스레드(thread)**를 할당하는 스레드 기반 모델을 채택한다.9 스레드는 프로세스보다 생성 비용이 훨씬 저렴하고 메모리를 공유하므로 컨텍스트 스위칭 오버헤드가 적다. 이 덕분에 수만 개의 동시 연결도 상대적으로 적은 시스템 자원으로 효율적으로 처리할 수 있어, 불특정 다수의 동시 접속이 빈번한 웹 기반 애플리케이션 환경에서 큰 강점을 보인다. 그러나 이 모델은 모든 스레드가 동일한 프로세스 메모리 공간을 공유하기 때문에, 하나의 스레드에서 발생하는 메모리 누수나 치명적인 오류가 전체 데이터베이스 서버 프로세스를 중단시킬 수 있는 잠재적인 위험을 내포하고 있다.

2.3 스토리지 구성

데이터의 영구 저장은 데이터 파일, 제어 파일, 트랜잭션 로그 파일이라는 세 가지 기본 파일 유형을 통해 이루어진다. 이는 모든 RDBMS의 공통적인 기반이다.15 그러나 이 파일들을 논리적으로 구성하고 관리하는 방식에는 차이가 있다.

• Oracle: **테이블스페이스(Tablespace)**라는 강력한 논리적 저장 단위를 통해 하나 이상의 물리적 데이터 파일을 그룹화하여 관리한다.15 이를 통해 관리자는 데이터의 종류(예: 인덱스, 사용자 데이터, 시스템 데이터)에 따라 저장 위치를 분리하고, 백업/복구 단위를 세분화하며, I/O를 분산시키는 등 정교한 스토리지 관리 전략을 구사할 수 있다. 또한, **ASM(Automatic Storage Management)**은 파일 시스템과 볼륨 관리자 역할을 데이터베이스 내부에 통합하여 스토리지 관리를 자동화하고 성능을 최적화하는 고급 기능을 제공한다.
• MS SQL Server: 데이터베이스는 하나의 **주 데이터 파일(.mdf)**과 선택적으로 여러 개의 보조 데이터 파일(.ndf), 그리고 **트랜잭션 로그 파일(.ldf)**로 구성된다.24 **파일 그룹(Filegroup)**이라는 개념을 통해 여러 데이터 파일을 논리적으로 묶어 관리할 수 있으며, 이를 이용해 특정 테이블이나 인덱스를 특정 파일 그룹에 배치하여 I/O 성능을 튜닝할 수 있다.
• MySQL/MariaDB: 스토리지 구성은 스토리지 엔진에 따라 달라지는 유연성을 보인다. InnoDB의 경우, innodb_file_per_table=ON 설정(현재 기본값)을 통해 각 테이블과 인덱스를 별도의 .ibd 파일에 저장한다.26 이는 테이블 단위의 백업, 복구, 이전을 용이하게 하여 관리 편의성을 크게 향상시킨다. MariaDB는 한 걸음 더 나아가, 분석 워크로드를 위해 설계된 ColumnStore와 같은 컬럼 기반 스토리지 엔진을 플러그인 형태로 제공한다.13 이는 단일 데이터베이스 시스템 내에서 OLTP용 행 기반 스토리지와 OLAP용 열 기반 스토리지를 함께 사용할 수 있는 HTAP(Hybrid Transactional/Analytical Processing) 아키텍처의 구현 가능성을 열어준다.
• PostgreSQL: 하나의 PostgreSQL 서버 인스턴스는 여러 데이터베이스를 포함하는 ’데이터베이스 클러스터’로 관리된다. 물리적으로 각 데이터베이스는 별도의 하위 디렉터리로 구성되며, 그 안에서 각 테이블과 인덱스는 하나 이상의 파일로 저장된다.8 Oracle이나 SQL Server와 유사하게 테이블스페이스 개념을 지원하여, 특정 데이터베이스 객체나 전체 데이터베이스의 물리적 저장 위치를 다른 디스크 볼륨으로 지정할 수 있는 유연성을 제공한다.

각 RDBMS의 근본적인 아키텍처 설계는 단순히 기술적인 차이를 넘어, 해당 시스템이 지향하는 목표와 철학을 반영한다. Oracle의 복잡하고 세분화된 구조는 숙련된 관리자에 의한 극한의 성능 튜닝 가능성을 열어두는 ’엔터프라이즈 철학’을 보여준다.14 반면, SQL Server의 통합 버퍼 풀과 MySQL의 단순한 스레드 모델은 ’관리 용이성과 빠른 개발’을 중시하는 실용주의적 접근을 나타낸다.4 PostgreSQL의 프로세스 기반 모델은 ’안정성과 격리’를 최우선 가치로 두는 학술적 배경에서 비롯되었음을 알 수 있다.22 이처럼 각기 다른 설계 철학은 성능 프로파일과 관리 오버헤드 사이의 고유한 트레이드오프를 만들어내며, 이는 RDBMS 선택의 가장 근본적인 고려사항이 된다.

또한, 프로세스/스레드 모델은 시스템의 확장성 패턴에 직접적인 영향을 미친다. 예를 들어, PostgreSQL의 프로세스 기반 모델은 동시 연결 수가 수천 개를 초과하면 메모리 소비와 컨텍스트 스위칭 비용으로 인해 성능 병목에 직면할 수 있다. 이 때문에 실제 운영 환경에서는 PgBouncer와 같은 외부 커넥션 풀러를 PostgreSQL 앞에 배치하는 것이 거의 표준적인 아키텍처 패턴으로 자리 잡았다. 이는 RDBMS 선택이 단순히 데이터베이스 자체의 성능을 넘어, 전체 시스템 스택의 구성과 아키텍처 패턴에까지 영향을 미치는 중요한 결정임을 보여준다. 반면, 스레드 기반의 MySQL이나 SQL Server는 내장된 스레드 풀링 메커니즘을 통해 다수의 동시 연결을 효율적으로 처리하므로 외부 풀러에 대한 의존도가 상대적으로 낮다.

마지막으로, 스토리지 아키텍처의 유연성은 해당 데이터베이스가 미래의 다양한 워크로드 변화에 얼마나 잘 적응할 수 있는지를 결정하는 중요한 척도가 된다. MySQL과 MariaDB의 ‘플러그형 스토리지 엔진’ 아키텍처는 이러한 유연성을 제공하는 핵심적인 전략적 자산이다.9 MariaDB가 분석 워크로드를 위해 ColumnStore 엔진을 통합한 것은, 전통적인 OLTP 강자가 HTAP이라는 새로운 시장으로 확장할 수 있는 길을 열어준 대표적인 사례다.13 이는 데이터베이스가 더 이상 단일 워크로드에만 묶이지 않고, 비즈니스의 변화에 따라 진화할 수 있는 능력을 갖추게 됨을 의미한다. 반면, 단일 스토리지 엔진을 가진 PostgreSQL은 이러한 구조적 유연성은 부족하지만, 대신 강력한 ‘확장(extension)’ 기능을 통해 외부 데이터 소스를 연동하거나(예: cstore_fdw) 유사한 기능을 구현하려는 시도를 하고 있다.28 이는 아키텍처 수준의 유연성과 기능 수준의 확장성 사이의 근본적인 차이를 보여주며, 장기적인 기술 로드맵을 수립할 때 신중하게 고려해야 할 부분이다.

3. 동시성 제어 메커니즘 심층 분석: 트랜잭션 처리의 핵심

다수의 사용자가 동시에 데이터를 읽고 쓰는 환경에서 데이터의 일관성을 유지하면서도 최고의 처리량을 확보하는 기술이 바로 동시성 제어(Concurrency Control)다. 현대적인 RDBMS의 OLTP 성능은 이 동시성 제어 메커니즘의 효율성에 의해 크게 좌우된다.

3.1 MVCC (Multi-Version Concurrency Control) 개요

MVCC는 오늘날 고성능 RDBMS의 표준으로 자리 잡은 동시성 제어 기법이다. 전통적인 잠금(Locking) 방식이 데이터에 대한 접근을 순차적으로 통제함으로써 동시성을 저해하는 문제를 해결하기 위해 고안되었다.29 그 핵심 원리는 데이터를 수정할 때 기존 데이터를 덮어쓰는 대신, 데이터의 새로운 버전을 만드는 것이다. 그리고 각 트랜잭션은 자신이 시작된 시점을 기준으로 일관된 데이터의 ’스냅샷(snapshot)’을 바라보게 된다.30 이로 인해 데이터를 읽는 트랜잭션(Reader)은 데이터를 쓰는 트랜잭션(Writer)을 기다릴 필요가 없고, 그 반대의 경우도 마찬가지다. 즉, “읽기는 쓰기를 막지 않고, 쓰기는 읽기를 막지 않는다“는 원칙이 구현되어 높은 동시성을 달성할 수 있다.31

3.2 MVCC 구현 방식 비교

대부분의 RDBMS가 MVCC를 채택하고 있지만, 그 내부 구현 방식에는 크게 두 가지 접근법이 존재하며, 이는 각 시스템의 성능 특성과 운영 방식에 결정적인 차이를 만들어낸다.

• PostgreSQL (In-Page/Heap-based Versioning):

PostgreSQL은 변경 이전 버전의 데이터를 별도의 공간으로 옮기지 않고, 원래의 테이블 파일(Heap) 내에 새로운 버전의 행(Tuple)을 추가하는 방식을 사용한다.33 UPDATE가 발생하면, PostgreSQL은 기존 행을 논리적으로 삭제 처리하고(내부적으로 xmax 트랜잭션 ID를 기록), 변경된 내용으로 새로운 행을 삽입한다.34

• 장점: 이 방식의 가장 큰 장점은 트랜잭션 롤백(Rollback)이 매우 빠르다는 점이다. 롤백을 위해 물리적으로 데이터를 되돌릴 필요 없이, 해당 트랜잭션의 상태를 ’중단(aborted)’으로 표시하기만 하면 되기 때문이다.34 시스템 장애 복구 시에도 복잡한 Undo 작업 없이 빠르게 재시작할 수 있다.

• 단점: 치명적인 단점은 더 이상 어떤 트랜잭션에서도 보이지 않게 된 이전 버전의 행, 즉 ’데드 튜플(Dead Tuple)’이 테이블 파일 내에 계속 남아 공간을 차지하고 성능을 저하시키는 ‘테이블 블로트(Table Bloat)’ 현상을 유발한다는 것이다.36 이를 해결하기 위해 PostgreSQL은 **VACUUM**이라는 주기적인 가비지 컬렉션 프로세스를 반드시 실행해야 한다. VACUUM 작업은 상당한 I/O 부하를 유발할 수 있으며, 이 작업이 제대로 관리되지 않을 경우 장시간 운영된 PostgreSQL 시스템의 성능 저하의 주된 원인이 된다.8

• Oracle & MySQL (InnoDB) (Undo Segment-based Versioning):

Oracle과 MySQL의 InnoDB 스토리지 엔진은 PostgreSQL과 다른 접근법을 취한다. UPDATE가 발생하면, 이들은 데이터가 저장된 원본 데이터 블록의 내용을 새로운 값으로 직접 덮어쓴다. 이때, 덮어쓰기 전의 이전 데이터는 Undo Segment (Oracle) 또는 **Rollback Segment (InnoDB)**라고 불리는 별도의 전용 공간에 백업된다.33

• 장점: 이 방식은 데드 튜플이 테이블 파일 내에 쌓이지 않으므로 테이블 블로트 문제가 근본적으로 발생하지 않는다. 따라서 PostgreSQL의 VACUUM과 같은 별도의 대규모 정리 작업이 필요 없다. Undo 데이터는 관련 트랜잭션이 모두 완료되면 시스템에 의해 점진적으로 재사용된다. 특히 InnoDB의 경우, 변경된 컬럼의 값만 Undo 로그에 기록하는 최적화를 통해 Undo 공간 사용의 효율성을 높이기도 한다.33
• 단점: 롤백 시 성능 부담이 있다. 트랜잭션을 롤백하려면 Undo Segment에 저장된 이전 버전의 데이터를 다시 가져와 원본 데이터 블록을 복구하는 물리적인 작업이 필요하다. 따라서 수백만 건의 데이터를 변경하는 대규모 트랜잭션이 롤백될 경우, PostgreSQL에 비해 상당한 시간이 소요될 수 있다.36 또한, 장시간 수행되는 쿼리가 있는 동안 많은 데이터 변경이 발생하면, 해당 쿼리가 필요로 하는 과거 버전의 Undo 데이터가 이미 재사용되어 사라져 ‘snapshot too old’ (Oracle)와 같은 오류가 발생할 수 있다.

3.3 MS SQL Server의 하이브리드 동시성 제어

MS SQL Server는 전통적인 잠금 방식과 현대적인 MVCC 방식을 모두 지원하는 독특한 하이브리드 모델을 제공한다.

• 기본 방식: 비관적 잠금 (Pessimistic Locking):

SQL Server의 기본 동작 방식은 전통적인 잠금 기반의 동시성 제어다. 이 방식은 데이터 충돌이 빈번하게 발생할 것이라고 가정(비관적)하고, 데이터에 접근하기 전에 미리 잠금을 획득하여 충돌을 원천적으로 방지한다. 데이터를 읽을 때는 공유 잠금(Shared Lock)을, 쓸 때는 배타적 잠금(Exclusive Lock)을 사용한다.35

• 장점: 데이터 충돌 가능성이 높은 환경에서 데이터의 일관성을 가장 강력하게 보장할 수 있다.

• 단점: 읽기와 쓰기가 서로를 차단(Blocking)하는 현상이 빈번하게 발생하여 시스템 전체의 동시성을 심각하게 저하시킬 수 있다. 또한, 여러 트랜잭션이 서로가 점유한 잠금을 기다리는 **교착 상태(Deadlock)**가 발생할 위험이 높다.35

• MVCC 옵션: 행 버전 관리 기반 격리 수준 (Row Versioning-based Isolation):

이러한 잠금 방식의 단점을 극복하기 위해, SQL Server 2005부터 MVCC 기반의 낙관적 동시성 제어 방식을 옵션으로 도입했다.31 이 기능은 데이터베이스 옵션 설정을 통해 활성화할 수 있다.

• Read Committed Snapshot Isolation (RCSI): ALTER DATABASE... SET READ_COMMITTED_SNAPSHOT ON 명령으로 활성화한다. 이 옵션이 켜지면, 기본 격리 수준인 READ COMMITTED에서 SELECT 문이 더 이상 공유 잠금을 사용하지 않는다. 대신, 다른 트랜잭션에 의해 수정 중인 행을 읽어야 할 경우, tempdb 데이터베이스에 저장된 커밋된 버전의 행 데이터를 읽는다. 이로써 읽기 작업은 쓰기 작업을 차단하지 않게 된다.
• Snapshot Isolation (SI): ALTER DATABASE... SET ALLOW_SNAPSHOT_ISOLATION ON 명령으로 활성화 후, 트랜잭션에서 SET TRANSACTION ISOLATION LEVEL SNAPSHOT을 명시적으로 사용해야 한다. 이는 트랜잭션 수준의 완전한 스냅샷을 제공하여, 트랜잭션 내의 모든 쿼리가 트랜잭션이 시작된 시점의 일관된 데이터를 보게 한다. 쓰기-쓰기 충돌은 커밋 시점에 감지되어, 나중에 커밋하려는 트랜잭션이 오류와 함께 롤백된다.
• 장점: 읽기와 쓰기 간의 차단 문제를 해결하여 OLTP 워크로드의 동시성과 처리량을 극적으로 향상시킨다.
• 단점: 모든 행 버전 정보가 **tempdb**에 저장되므로, tempdb의 공간 사용량과 I/O 부하가 증가하는 오버헤드가 발생한다.35 tempdb의 성능이 전체 시스템 성능에 중요한 영향을 미치게 된다.

MVCC 구현 방식의 차이는 단순히 기술적 선택을 넘어, 각 RDBMS가 지향하는 운영 모델과 철학의 차이를 드러낸다. PostgreSQL의 VACUUM 요구사항은 “데이터베이스의 건강 상태는 DBA가 능동적으로 관리해야 한다“는 철학을 반영하는 반면 36, Oracle/InnoDB의 자동화된 Undo 관리는 “시스템은 가능한 한 스스로 최적화되어야 한다“는 상용 DBMS의 철학과 맞닿아 있다. SQL Server가 RCSI를 옵션으로 제공하는 것은 “기존 애플리케이션의 호환성을 유지하면서도, 필요에 따라 현대적인 동시성 제어의 이점을 취할 수 있도록 선택권을 제공한다“는 실용주의적 접근을 보여준다.

이러한 구현 방식의 차이는 성능 트레이드오프로 이어진다. PostgreSQL의 UPDATE는 사실상 DELETE와 INSERT의 조합으로, 변경되지 않은 컬럼까지 포함한 행 전체를 새로 기록해야 한다. 이는 ’쓰기 증폭(Write Amplification)’을 유발하고 WAL(Write-Ahead Log) 생성량을 증가시킨다.33 반면, 과거 데이터를 읽기 위해 다른 곳을 참조할 필요가 없어 ’읽기 증폭(Read Amplification)’은 적다. 이와 대조적으로, Oracle/InnoDB는 변경된 데이터만 Undo Segment에 기록하여 ’쓰기 증폭’이 적지만, 일관된 읽기를 위해 현재 데이터 블록과 Undo 블록을 모두 읽고 재구성해야 하므로 ’읽기 증폭’이 발생할 수 있다.33 이 트레이드오프는 워크로드 특성에 따라 성능에 지대한 영향을 미친다.

특히, SQL Server의 RCSI는 많은 레거시 애플리케이션을 보유한 기업에게 매우 중요한 가치를 제공한다. 완전한 MVCC 기반 시스템으로의 마이그레이션은 애플리케이션 로직의 대대적인 수정과 테스트를 요구하는 고비용, 고위험 프로젝트다. 하지만 RCSI는 데이터베이스 설정 변경만으로, 애플리케이션 코드 수정 없이도 읽기 작업의 블로킹 문제를 해결할 수 있는 강력하고 현실적인 경로를 제공한다.35 이는 기업이 기존의 기술 자산을 보호하면서도 성능 병목을 해결할 수 있는 ‘점진적이고 저위험’ 현대화 전략을 가능하게 하며, SQL Server가 엔터프라이즈 시장에서 강력한 경쟁력을 유지하는 핵심 요인 중 하나로 작용한다.

4. 인덱싱 전략과 워크로드별 성능 최적화

인덱스는 대용량 데이터 속에서 원하는 정보를 빠르게 찾기 위한 필수적인 기술이다. 어떤 유형의 인덱스를 어떻게 활용하는지에 따라 쿼리 성능은 수십, 수백 배까지 차이가 날 수 있다. 각 RDBMS는 다양한 인덱싱 전략을 제공하며, 이는 특정 워크로드에 최적화된 성능을 이끌어내는 핵심 열쇠가 된다.

4.1 B-Tree 인덱스

B-Tree(Balanced Tree) 인덱스는 거의 모든 관계형 데이터베이스에서 기본으로 채택하고 있는 가장 보편적인 인덱스 구조다.38 데이터 값을 정렬된 트리 구조로 유지함으로써, 특정 값을 찾거나(Point Lookup), 특정 범위 내의 값을 검색하거나(Range Scan), 결과를 정렬하는 작업에 매우 높은 효율을 보인다.40

• 적합한 워크로드 (OLTP): B-Tree 인덱스는 소수의 특정 행을 고유 식별자(Primary Key 등)로 빠르게 찾아 읽고 쓰는 작업이 빈번한 OLTP(Online Transaction Processing) 워크로드에 절대적으로 적합하다.41 WHERE customer_id = 12345와 같은 쿼리는 B-Tree 인덱스를 통해 최소한의 I/O로 즉시 원하는 행을 찾을 수 있다.
• 한계: 인덱스된 컬럼의 고유 값 종류(Cardinality)가 매우 적은 경우(예: ‘남/여’ 두 가지만 있는 성별 컬럼)에는 효율이 떨어진다. 또한, 테이블의 상당 부분(일반적으로 5~10% 이상)을 읽어야 하는 광범위한 쿼리의 경우, 인덱스를 스캔하는 것보다 테이블 전체를 순차적으로 읽는 ’풀 테이블 스캔(Full Table Scan)’이 더 빠를 수 있다. 대부분의 B-Tree 인덱스 구현은 모든 값이 NULL인 행은 인덱스에 포함하지 않는다는 특징도 있다.41

4.2 Bitmap 인덱스

Bitmap 인덱스는 데이터 웨어하우징(DW) 및 분석(OLAP) 환경을 위해 설계된 특수한 인덱스 유형으로, 특히 Oracle에서 강력한 기능을 제공한다.42 이 인덱스는 컬럼에 존재하는 각 고유 값에 대해, 해당 값을 가진 행들의 위치를 1과 0으로 표현하는 비트맵(bit array)을 만들어 저장한다.

• 적합한 워크로드 (OLAP):
• 낮은 카디널리티 컬럼: 성별, 회원 등급, 제품 카테고리와 같이 고유 값의 종류가 적은 컬럼에서 B-Tree 인덱스에 비해 월등히 작은 저장 공간을 차지하며 높은 압축률을 보인다.38
• 복합 조건 쿼리 처리: Bitmap 인덱스의 진정한 위력은 여러 조건을 결합하는 쿼리에서 발휘된다. 예를 들어, “성별이 ’남성’이고, 거주지가 ’서울’이며, 회원 등급이 ’VIP’인 고객“을 찾는 쿼리가 있다고 가정하자. 각 컬럼에 Bitmap 인덱스가 있다면, 데이터베이스는 ‘남성’ 비트맵, ‘서울’ 비트맵, ‘VIP’ 비트맵을 가져와 CPU 수준에서 매우 빠른 비트 단위 AND 연산을 수행한다. 이 연산 결과로 최종 조건을 만족하는 행들의 위치 정보가 담긴 새로운 비트맵을 즉시 얻을 수 있다.39 이는 여러 B-Tree 인덱스를 각각 스캔하고 그 결과를 병합하는 방식보다 훨씬 효율적이다. Oracle에서는 B-Tree 인덱스를 여러 개 사용하는 쿼리에 5개라는 제한이 있지만, Bitmap 인덱스에는 이러한 제한이 없다.42
• 한계: Bitmap 인덱스는 데이터 변경(DML) 작업에 매우 취약하다. 단 하나의 행 값이 변경되더라도, 해당 값이 포함된 비트맵의 일부 또는 전체에 잠금이 발생할 수 있어 동시 DML이 많은 OLTP 환경에는 절대적으로 부적합하다.41 이 때문에 주로 데이터 로딩이 주기적으로 일어나는 데이터 웨어하우스 환경에서 사용된다.

4.3 컬럼스토어 인덱스

컬럼스토어 인덱스는 데이터를 전통적인 행(row) 단위가 아닌 열(column) 단위로 저장하고 압축하는 혁신적인 방식이다. 이는 대규모 데이터 분석 쿼리의 성능을 획기적으로 향상시키기 위해 고안되었다.

• 개요: 수십, 수백 개의 컬럼으로 구성된 거대한 테이블에서 단 몇 개의 컬럼만을 집계하는 분석 쿼리(예: SELECT SUM(매출액) FROM 판매내역 WHERE 판매일자 BETWEEN '2023-01-01' AND '2023-12-31')를 생각해보자. 행 기반 저장 방식에서는 이 쿼리를 위해 모든 컬럼의 데이터를 디스크에서 읽어야 하지만, 열 기반 저장 방식에서는 ’매출액’과 ‘판매일자’ 컬럼의 데이터만 읽으면 된다. 이로 인해 I/O 양이 극적으로 감소한다. 또한, 동일한 데이터 타입의 값들이 연속으로 저장되므로 압축 효율이 매우 높아 스토리지 비용을 절감하는 효과도 크다. MS SQL Server는 이 기술을 데이터베이스 엔진의 핵심 기능으로 통합했으며 44, MariaDB는 ColumnStore 스토리지 엔진을 통해 13, Oracle은 In-Memory Column Store 기능을 통해 이를 지원한다.17
• MS SQL Server의 구현: SQL Server는 클러스터형 및 비클러스터형 컬럼스토어 인덱스를 모두 제공한다. 특히, 쿼리 실행 시 **‘배치 모드 실행(Batch Mode Execution)’**이라는 최적화 기법을 사용한다. 이는 한 번에 하나의 행을 처리하는 대신, 수백 개의 행으로 구성된 ‘배치’ 단위로 데이터를 처리하는 벡터 기반 연산 방식이다. 이를 통해 CPU 캐시 효율을 극대화하고 명령어 처리량을 높여 분석 쿼리의 속도를 한 차원 더 끌어올린다.44
• 한계: 특정 행 하나에 대한 모든 컬럼 값을 가져오거나, 소수의 행을 빈번하게 UPDATE하는 OLTP성 쿼리에는 행 기반 저장 방식보다 비효율적이다. 데이터 변경 비용이 상대적으로 높기 때문이다.

인덱스 전략의 포트폴리오는 각 RDBMS 벤더가 목표로 하는 주력 워크로드와 시장 전략을 명확하게 보여주는 지표다. 모든 RDBMS가 B-Tree를 기본으로 제공하는 것은 OLTP가 관계형 데이터베이스의 근본임을 상징한다. Oracle이 오랫동안 Bitmap 인덱스의 우수성을 강조해온 것은 엔터프라이즈 데이터 웨어하우스 시장에서의 전통적인 강자임을 드러낸다.42 MS SQL Server가 컬럼스토어 인덱스를 엔진 깊숙이 통합하고 ’배치 모드 실행’과 같은 고유한 최적화까지 구현한 것은, 단순한 데이터 저장소를 넘어 BI 및 분석 플랫폼으로서의 정체성을 강화하려는 전략적 의지를 보여준다.44 MariaDB가 ColumnStore 엔진을 인수하여 자사 생태계에 편입시킨 것은 오픈소스 진영에서도 OLAP 및 HTAP 시장으로의 확장이 얼마나 중요한 과제인지를 시사한다.13

특히 OLAP 환경에서 성능을 가르는 결정적인 차이는 ’인덱스 조합 가능성’에서 비롯된다. OLTP 환경은 쿼리 패턴이 비교적 정형화되어 있어, 자주 사용되는 조건절에 맞춰 최적의 B-Tree 복합 인덱스를 사전에 설계할 수 있다. 그러나 OLAP 환경의 쿼리는 사용자가 어떤 컬럼 조합으로 데이터를 필터링하고 분석할지 예측하기 어려운 ‘애드혹(Ad-hoc)’ 쿼리가 대부분이다. B-Tree 인덱스는 인덱스 생성 시 정의된 컬럼 순서에 의존적이므로, 수많은 애드혹 쿼리 패턴을 모두 지원하기 위해 수십 개의 복합 인덱스를 만드는 것은 비현실적이다. 바로 이 지점에서 Bitmap 인덱스의 ‘동적 최적화’ 능력이 빛을 발한다. 각 컬럼에 대해 개별 Bitmap 인덱스만 생성해두면, 쿼리 옵티마이저는 런타임에 어떤 조합의 조건절이 들어오더라도 해당 비트맵들을 비트 연산으로 빠르게 결합하여 최적의 실행 계획을 동적으로 수립할 수 있다.42

최근 실시간 분석에 대한 요구가 증대하며 등장한 HTAP(Hybrid Transactional/Analytical Processing) 패러다임은 인덱싱 전략에 근본적인 변화를 요구하고 있다. 전통적으로 OLTP와 OLAP는 물리적으로 분리된 시스템에서 각기 다른 인덱스 전략(B-Tree vs. Bitmap/Columnstore)을 사용했다. 그러나 단일 시스템에서 두 워크로드를 동시에 처리하려는 HTAP 환경에서는 이러한 상충되는 요구사항을 조화시켜야 하는 난제에 직면한다. MS SQL Server가 트랜잭션용 rowstore 테이블 위에 분석용 비클러스터형 컬럼스토어 인덱스를 생성할 수 있도록 허용한 것이나 44, Oracle이 OLTP 데이터가 저장된 버퍼 캐시를 메모리 내에서 동적으로 컬럼 포맷으로 변환하여 분석하는 In-Memory Column Store 기능을 제공하는 것 17은 바로 이 문제를 해결하기 위한 아키텍처적 진화의 결과다. 이는 더 이상 ’OLTP용 인덱스’와 ’OLAP용 인덱스’를 분리해서 사고할 수 없으며, 두 워크로드를 동시에 만족시키는 하이브리드 인덱싱 및 데이터 저장 전략이 차세대 RDBMS 성능의 핵심 과제로 부상했음을 명확히 보여준다.

5. 확장성 및 고가용성 솔루션: 무중단 서비스와 스케일 아웃

비즈니스가 성장함에 따라 데이터와 트랜잭션의 양은 기하급수적으로 증가한다. 이러한 부하 증가에 대응하여 시스템 성능을 선형적으로 확장하고, 하드웨어나 소프트웨어 장애 발생 시에도 서비스 중단을 최소화하는 능력은 현대 RDBMS의 핵심 경쟁력이다. 각 RDBMS는 서로 다른 아키텍처 철학을 바탕으로 고유한 확장성 및 고가용성(HA) 솔루션을 제공한다.

5.1 Oracle RAC (Real Application Clusters)

Oracle RAC는 업계에서 가장 독보적이고 성숙한 데이터베이스 클러스터링 기술로 평가받는다.

• 아키텍처: 다수의 서버(노드)가 단일 공유 스토리지(Shared Disk)에 저장된 동일한 데이터베이스 파일을 공유하는 Shared-Everything 아키텍처를 기반으로 한다.45 클러스터를 구성하는 모든 노드는 Active 상태로 동작하며, 어떤 노드로든 데이터베이스에 대한 읽기/쓰기 요청을 동시에 처리할 수 있다(Active-Active 클러스터).14
• 핵심 기술 (Cache Fusion): RAC의 성능과 일관성을 보장하는 핵심 기술은 Global Cache Service (GCS), 일명 Cache Fusion이다.46 특정 노드에서 데이터 블록을 수정하면, 이 변경 사항이 디스크에 기록되기 전에 고속의 전용 네트워크(Interconnect)를 통해 다른 노드의 메모리 캐시(SGA)로 직접 전송된다. 다른 노드가 해당 블록을 필요로 할 때, 디스크에서 읽는 대신 다른 노드의 메모리에서 직접 가져오는 것이다. 이를 통해 여러 노드에서 동시에 데이터에 접근하더라도 데이터 일관성을 완벽하게 보장하면서 디스크 I/O를 획기적으로 줄인다.
• 성능 특성 (쓰기 확장성): RAC의 가장 큰 장점은 OLTP 워크로드의 **쓰기 확장성(Write Scalability)**이다. 대부분의 다른 HA 솔루션이 단일 쓰기 노드(Primary)의 성능 한계에 부딪히는 반면, RAC는 클러스터에 노드를 추가함에 따라 쓰기 처리 용량을 거의 선형적으로 증가시킬 수 있다. 더 중요한 것은 이러한 확장이 애플리케이션의 코드 수정 없이 투명하게 이루어진다는 점이다.45
• 고가용성: 클러스터 내의 한 노드에서 하드웨어나 소프트웨어 장애가 발생하면, Oracle Clusterware가 이를 즉시 감지한다. 그리고 해당 노드에서 처리 중이던 클라이언트 세션들을 다른 정상 노드로 자동으로 재연결하고 트랜잭션을 복구(Failover)하여 서비스 중단을 수 초 이내로 최소화한다.48

5.2 MS SQL Server Always On 가용성 그룹

Always On 가용성 그룹(AG)은 SQL Server 2012부터 도입된 현대적인 고가용성 및 재해 복구(DR) 솔루션이다.

• 아키텍처: 각 노드가 자신만의 독립적인 로컬 스토리지를 사용하는 Shared-Nothing 아키텍처를 기반으로 한다. AG는 하나의 **주 복제본(Primary Replica)**과 최대 8개의 **보조 복제본(Secondary Replicas)**으로 구성된다. 모든 쓰기(DML) 작업은 주 복제본에서만 수행되며, 발생한 트랜잭션 로그가 보조 복제본으로 전송되어 데이터가 동기화된다.49
• 복제 모드:
• 동기 커밋(Synchronous-commit): 고가용성(HA)을 위해 사용된다. 주 복제본은 트랜잭션을 커밋하기 전에, 최소 하나 이상의 동기 모드 보조 복제본에 해당 트랜잭션 로그가 안전하게 기록되었음을 확인한 후에 클라이언트에 응답한다. 이 방식은 주 복제본 장애 시에도 데이터 손실이 전혀 없는(RPO=0) 자동 장애 조치를 보장하지만, 보조 복제본의 확인을 기다리는 시간만큼 트랜잭션 지연 시간(latency)이 증가한다.49
• 비동기 커밋(Asynchronous-commit): 주로 원격지의 재해 복구(DR) 사이트를 구성하는 데 사용된다. 주 복제본은 보조 복제본의 응답을 기다리지 않고 즉시 트랜잭션을 커밋한다. 이 방식은 트랜잭션 성능에 거의 영향을 주지 않지만, 주 복제본에 심각한 장애가 발생했을 때 아직 보조 복제본으로 전송되지 않은 트랜잭션이 유실될 수 있다(RPO>0).49
• 성능 특성 (읽기 확장성): AG의 주요 강점 중 하나는 **읽기 확장성(Read Scale-out)**이다. 보조 복제본들을 **읽기 가능한 보조 복제본(Readable Secondaries)**으로 설정하여, 분석 쿼리나 리포팅과 같은 읽기 전용 워크로드를 이들 보조 복제본으로 분산시킬 수 있다. 이를 통해 주 복제본은 쓰기 트랜잭션 처리에만 집중할 수 있어 전체 시스템의 처리량을 향상시킬 수 있다.52
• 고가용성: 동기 모드로 구성된 주 복제본에 장애가 발생하면, WSFC(Windows Server Failover Clustering) 서비스가 이를 자동으로 감지하고, 미리 지정된 보조 복제본을 새로운 주 복제본으로 즉시 승격시켜 서비스 중단을 최소화하는 자동 장애 조치를 수행한다.51

5.3 PostgreSQL 스트리밍 복제 & 자동 장애 조치

PostgreSQL은 강력한 내장 복제 기능과 활발한 오픈소스 생태계의 외부 도구를 결합하여 유연한 고가용성 환경을 구축한다.

• 아키텍처: SQL Server AG와 마찬가지로, 각 노드가 독립적인 스토리지를 사용하는 Shared-Nothing 기반의 주/복제(Primary/Replica 또는 Master/Standby) 구조다. 주 서버에서 발생하는 모든 데이터 변경 사항은 WAL(Write-Ahead Log) 레코드로 기록되며, 이 WAL 레코드를 네트워크를 통해 하나 이상의 복제 서버로 실시간 전송(Streaming)하여 데이터를 동기화한다.54
• 복제 유형:
• 물리적 복제(Physical Replication): WAL 레코드를 바이너리(물리적) 수준에서 그대로 복제 서버에 적용하는 방식이다. 구성이 간단하고 성능이 뛰어나며, 주 서버와 거의 동일한 복제본을 만들 수 있다.54
• 논리적 복제(Logical Replication): WAL 레코드를 INSERT, UPDATE, DELETE와 같은 논리적인 변경 작업으로 디코딩하여 복제하는 방식이다. 이를 통해 특정 테이블이나 특정 조건에 맞는 데이터만 선택적으로 복제하거나, 서로 다른 PostgreSQL 버전 간에도 복제가 가능해지는 등 높은 유연성을 제공한다.54
• 동기/비동기 모드: SQL Server와 마찬가지로, 트랜잭션 커밋 시 복제 서버의 확인을 기다릴지 여부에 따라 동기 및 비동기 모드를 모두 지원한다. 이를 통해 데이터 일관성 수준과 성능 사이에서 필요에 맞는 선택이 가능하다.57
• 자동 장애 조치: PostgreSQL 코어 엔진 자체에는 주 서버의 장애를 감지하고 자동으로 복제 서버를 승격시키는 기능이 내장되어 있지 않다. 이러한 자동 장애 조치 기능은 Patroni, repmgr과 같은 검증된 외부 오픈소스 클러스터 관리 도구를 사용하여 구현해야 한다. 이들 도구는 분산 코디네이션 시스템(etcd, Consul 등)을 활용하여 클러스터 전체의 상태를 감시하고, 주 서버 장애 시 ‘리더 선출(Leader Election)’ 과정을 통해 새로운 주 서버를 안정적으로 승격시키는 역할을 수행한다.54 이는 높은 구성 유연성을 제공하는 장점이 있지만, 여러 컴포넌트를 조합해야 하는 관리상의 복잡성을 수반한다.

5.4 MySQL/MariaDB 다중 마스터 복제

MySQL/MariaDB 생태계는 전통적인 주/복제 방식 외에도, 모든 노드가 쓰기 작업을 처리할 수 있는 다중 마스터(Multi-Master) 클러스터링 솔루션을 제공한다.

• Galera Cluster: MySQL/MariaDB를 위한 가장 대표적인 동기식, 다중 마스터 복제 솔루션이다. Galera 클러스터의 모든 노드는 읽기와 쓰기 작업을 모두 처리할 수 있는 Active-Active 상태로 동작한다. 특정 노드에서 트랜잭션이 커밋되면, 변경 사항(writeset)이 그룹 통신을 통해 다른 모든 노드에 전파된다. 모든 노드가 이 변경 사항을 자신의 데이터 상태와 비교하여 충돌이 없는지 ’인증(certification)’하는 과정을 거치며, 모든 노드에서 인증이 성공해야만 해당 트랜잭션이 최종적으로 모든 노드에 커밋된다.59
• 성능 특성: 이 방식은 모든 노드가 항상 동일한 데이터를 가지도록 보장하므로 데이터 정합성이 매우 높고, 전통적인 복제 방식의 고질적인 문제인 ’복제 지연(replication lag)’이 원천적으로 발생하지 않는다. 또한, 어떤 노드로든 쓰기 요청을 보낼 수 있어 쓰기 부하 분산에 유리하다. 하지만 단점도 명확하다. 서로 다른 노드에서 동시에 같은 데이터를 수정하려는 **쓰기 충돌(Write Conflict)**이 발생하면, 나중에 인증을 요청한 트랜잭션은 강제로 롤백된다. 따라서 쓰기 충돌이 빈번한 워크로드에서는 롤백률이 높아져 오히려 성능이 저하될 수 있다. 또한, 모든 노드의 인증을 기다려야 하므로, 특히 노드 간 네트워크 지연 시간(latency)이 긴 WAN 환경에서는 커밋 지연 시간이 길어지는 단점이 있다.59
• 기타 솔루션: 이 외에도 전통적인 비동기/반동기(asynchronous/semi-synchronous) 주/복제 방식이 여전히 널리 사용되고 있으며, Oracle이 제공하는 MySQL InnoDB Cluster는 그룹 복제(Group Replication) 기술을 기반으로 한 고가용성 솔루션을 제공하여 Galera와 경쟁하고 있다.59

확장성 및 고가용성 아키텍처의 선택은 ’데이터 일관성’과 ‘성능’ 사이의 근본적인 트레이드오프를 어떻게 가져갈 것인가의 문제다. Oracle RAC의 Shared-Everything 아키텍처는 Cache Fusion이라는 복잡하고 비용이 높은 기술을 통해 강력한 일관성과 쓰기 확장성을 동시에 달성한다.45 반면, PostgreSQL이나 SQL Server의 Shared-Nothing 복제 방식은 구조가 단순하고 비용 효율적이지만, 동기 복제 시 쓰기 지연 시간 증가를, 비동기 복제 시에는 데이터 유실 가능성을 감수해야 한다.49 Galera Cluster는 동기식 다중 마스터로 일관성을 극대화하지만, 쓰기 충돌 처리와 커밋 지연이라는 또 다른 형태의 성능 비용을 지불한다.59

또한, ’솔루션의 통합 수준’은 운영의 복잡성과 안정성을 결정하는 중요한 요소다. Oracle RAC와 SQL Server Always On은 OS, 클러스터웨어, 데이터베이스가 벤더에 의해 긴밀하게 통합된 ’일체형 솔루션’으로, 일단 구축되면 예측 가능하고 안정적으로 동작하며 단일 벤더로부터 통합 지원을 받을 수 있다.48 반면, PostgreSQL의 HA 생태계는 스트리밍 복제라는 강력한 코어 기능 위에 Patroni, PgBouncer, etcd 등 여러 오픈소스 컴포넌트를 조합하여 구성된다. 이는 높은 유연성과 비용 효율성을 제공하지만, 각 컴포넌트 간의 호환성, 버전 관리, 장애 분석 등 운영 복잡성이 기하급수적으로 증가하는 단점이 있다. 이는 상용 솔루션이 ’초기 도입 비용’을, 오픈소스 솔루션이 ’운영 비용(특히 인적 자원)’을 더 많이 요구하는 경향으로 이어진다.

궁극적으로, ’읽기 확장성(Read Scale-out)’은 대부분의 RDBMS가 복제본을 통해 비교적 쉽게 해결할 수 있는 문제가 되었지만, 애플리케이션 수정 없이 단일 데이터베이스에 대한 ’투명한 쓰기 확장성(Transparent Write Scale-out)’은 여전히 극도로 어려운 과제로 남아있다. 현재 이 문제를 가장 성숙하게 해결한 상용 솔루션은 Oracle RAC 뿐이다.45 이 ’투명한 쓰기 확장성’의 유무가 오늘날에도 여전히 Oracle RAC가 고가의 라이선스 비용에도 불구하고 대규모 미션 크리티컬 OLTP 시스템에서 대체 불가능한 선택지로 남게 하는 가장 결정적인 이유다.

6. 쿼리 처리 및 최적화

사용자가 던진 SQL 문장이 어떻게 파싱되고, 어떤 실행 경로를 거쳐 결과를 반환하는지는 데이터베이스의 ’지능’에 해당하는 부분이다. 쿼리 옵티마이저(Query Optimizer)의 성능은 복잡한 쿼리의 응답 시간을 수 초에서 수 시간으로 바꿀 수 있을 만큼 결정적인 역할을 한다.

• 쿼리 처리 단계: 모든 RDBMS는 유사한 쿼리 처리 단계를 거친다.

1. 파싱(Parsing): SQL 문장의 구문(Syntax)과 의미(Semantic)를 분석하여 내부적인 자료 구조(Parse Tree)로 변환한다.4
2. 최적화(Optimization): 쿼리 옵티마이저가 파싱된 트리를 기반으로, 동일한 결과를 내는 수많은 가능한 실행 방법(Execution Plan)들 중에서 가장 비용(Cost)이 적게 드는 최적의 계획을 선택한다. 이 과정에서 테이블 통계 정보, 인덱스 정보 등을 활용한다.4
3. 실행(Execution): 쿼리 실행기(Query Executor)가 옵티마이저가 선택한 실행 계획에 따라 스토리지 엔진으로부터 데이터를 가져오고, 조인, 정렬, 그룹화 등의 연산을 수행하여 최종 결과를 생성한다.4

• 옵티마이저 아키텍처 비교:
• Oracle: 가장 정교하고 성숙한 비용 기반 옵티마이저(Cost-Based Optimizer, CBO)를 자랑한다. 수집된 통계 정보를 바탕으로 각 연산의 비용을 정밀하게 계산하며, 다양한 조인 방식(Nested Loop, Hash, Sort Merge), 접근 경로(Index Scan, Full Table Scan), 쿼리 변환(Query Transformation) 기법을 활용하여 최적의 실행 계획을 찾는다. 특히 복잡한 쿼리와 대용량 데이터셋에서 강점을 보인다.2
• MS SQL Server: Oracle과 마찬가지로 강력한 비용 기반 옵티마이저를 탑재하고 있다. 쿼리 실행 중 실제 데이터 분포가 예상과 다를 경우 실행 계획을 동적으로 조정하는 적응형 쿼리 처리(Adaptive Query Processing)와 같은 지능적인 기능을 제공한다. 또한, 컬럼스토어 인덱스를 위한 배치 모드 실행(Batch Mode Execution)은 분석 쿼리 성능을 극대화한다.44
• PostgreSQL: 매우 진보된 오픈소스 쿼리 옵티마이저를 가지고 있다. 다양한 조인 전략과 고급 인덱싱(GIN, GiST 등)을 효과적으로 활용하며, 복잡한 분석 쿼리 처리 능력에서 상용 RDBMS에 필적하는 성능을 보여준다.60 유전 알고리즘(Genetic Algorithm)을 사용하여 조인 순서가 매우 많은 복잡한 쿼리의 최적화를 시도하는 기능도 포함되어 있다.
• MySQL/MariaDB: 역사적으로 단순한 쿼리에 최적화되어 있었으나, 최신 버전으로 오면서 옵티마이저가 크게 발전했다. 하지만 여전히 서브쿼리 최적화나 복잡한 조인 처리 능력에서는 PostgreSQL이나 상용 RDBMS에 비해 부족한 면이 있다는 평가를 받는다.6 MariaDB는 MySQL에서 파생되었지만, 독자적인 옵티마이저 개선을 통해 성능 향상을 꾀하고 있다.61

각 RDBMS의 성능 특성은 메모리 활용 방식에서도 차이를 보인다. Oracle은 AMM(Automatic Memory Management)을 통해 메모리 자원을 동적으로 할당하여 대용량 데이터셋을 효율적으로 처리한다.3 SQL Server는 동적 메모리 할당으로 워크로드에 따라 자원을 조정하며, MySQL은 상대적으로 가볍고 메모리 효율적이어서 소규모 애플리케이션에 이상적이다. PostgreSQL은 복잡한 쿼리와 대용량 데이터 구조에 대해 메모리를 효과적으로 처리하며, 특히 분석 워크로드에서 뛰어난 성능을 보인다.3

프로그래밍 언어 지원 측면에서는, Oracle은 PL/SQL, SQL Server는 T-SQL이라는 각자의 절차적 언어 확장을 제공한다.63 PostgreSQL은 PL/pgSQL을 기본으로 하면서도 Python, Perl, Tcl 등 다양한 언어로 함수를 작성할 수 있는 뛰어난 유연성을 제공한다.21 MySQL은 저장 프로시저 기능이 상대적으로 제한적이다. 이러한 언어적 차이는 복잡한 비즈니스 로직을 데이터베이스 내에서 구현할 때 개발 생산성과 성능에 영향을 미칠 수 있다.

7. TPC 벤치마크 기반 성능 평가: 실증적 데이터 분석

아키텍처와 내부 메커니즘에 대한 이론적 분석은 실제 워크로드 하에서의 성능을 검증하는 실증적 데이터로 뒷받침되어야 한다. TPC(Transaction Processing Performance Council)에서 제정한 표준 벤치마크는 이러한 목적을 위한 업계의 공인된 척도로 사용된다.66

7.1 벤치마크 개요 및 해석 시 유의점

• TPC-C: 온라인 트랜잭션 처리(OLTP) 성능을 측정하는 표준 벤치마크다. 도매 공급업체의 주문, 결제, 재고 확인 등 5가지 유형의 트랜잭션을 복합적으로 실행하여 실제 OLTP 환경을 시뮬레이션한다. 주요 성능 지표는 분당 처리되는 신규 주문 트랜잭션 수인 **tpmC (transactions per minute C)**이다.66
• TPC-H: 의사결정 지원 시스템(DSS), 즉 OLAP 성능을 측정하는 벤치마크다. 대용량 데이터를 대상으로 22개의 복잡한 비즈니스 분석 쿼리를 실행한다. 주요 지표는 시간당 쿼리 처리량을 나타내는 **QphH@Size (Composite Query-per-Hour Performance Metric at a given Scale Factor)**이다.67
• 해석 시 유의점: TPC에서 공식적으로 감사하고 발표하는 결과는 특정 하드웨어, 운영체제, 데이터베이스 버전, 그리고 정교한 튜닝의 조합에 대한 결과다. 따라서 TPC 규정은 서로 다른 데이터베이스 크기(@Size)나 다른 시점에 측정된 결과를 직접 비교하는 것을 권장하지 않는다.67 또한, 많은 벤더나 커뮤니티에서 발표하는 성능 자료는 HammerDB, Sysbench와 같은 도구를 사용하여 TPC 워크로드를 모방한 ‘TPC-like’ 테스트 결과인 경우가 많다. 이러한 결과는 공식 TPC 결과와 직접 비교할 수 없으며, 테스트 조건과 구성을 면밀히 살펴 경향성을 파악하는 데 중점을 두어야 한다.70

7.2 TPC-C (OLTP) 벤치마크 결과 분석

• Oracle: 역사적으로 TPC-C 벤치마크에서 가장 높은 성능 기록을 다수 보유하고 있다. 특히 RAC(Real Application Clusters) 구성을 통해 여러 노드로 확장하여 수백만 tpmC를 달성하는 등, 대규모 OLTP 워크로드에서의 압도적인 확장성을 입증해왔다.68 이는 Shared-Everything 아키텍처와 Cache Fusion 기술이 쓰기 중심의 트랜잭션을 얼마나 효율적으로 처리하는지를 보여주는 실증적 증거다.
• MS SQL Server: 단일 노드 성능은 물론, 클러스터 구성을 통해서도 매우 높은 tpmC를 기록하며 Oracle과 치열하게 경쟁한다. 다양한 하드웨어 벤더들이 SQL Server를 사용하여 TPC-C 결과를 발표하고 있으며, 이는 SQL Server가 엔터프라이즈급 OLTP 성능을 충분히 제공함을 보여준다. Nutanix 환경에서의 HammerDB 테스트 결과에 따르면, 단일 SQL Server 인스턴스가 86만 TPM 이상을 기록했으며, 메모리와 vCPU를 확장함에 따라 성능이 향상되는 것을 확인할 수 있다.70
• MySQL/MariaDB: 공식 TPC-C 결과는 없지만, 다양한 ‘TPC-C like’ 테스트(주로 Sysbench나 HammerDB 사용)에서 높은 처리량을 보여준다. 그러나 테스트 결과들을 종합해 보면, 동시 사용자(스레드) 수가 특정 임계점(예: 64 또는 128)을 넘어서면 내부적인 잠금 경합(lock contention)으로 인해 오히려 처리량이 감소하는 경향이 종종 관찰된다.72 이는 스레드 모델과 InnoDB의 잠금 메커니즘이 초고도의 동시성 환경에서 한계를 보일 수 있음을 시사한다. 그럼에도 불구하고 MySQL 8.0은 이전 버전에 비해 TPC-C 워크로드에서 상당한 성능 향상을 이루었다.72
• PostgreSQL: ‘TPC-C like’ 테스트에서 준수한 성능을 보여준다. Google Cloud의 AlloyDB(PostgreSQL 호환) 성능 테스트 결과에 따르면, 데이터베이스가 메모리에 완전히 캐시되는지(fully cached) 여부에 따라 성능이 크게 달라지는 것으로 나타났다.75 이는 PostgreSQL의 성능이 I/O 서브시스템의 성능에 민감하게 반응하며, 충분한 메모리와 빠른 스토리지가 중요함을 의미한다. pgbench와 같은 PostgreSQL 고유의 벤치마크에서는 매우 높은 TPS(초당 트랜잭션 수)를 기록하기도 한다.76

7.3 TPC-H (OLAP) 벤치마크 결과 분석

• MS SQL Server: TPC-H 공식 결과에서 가장 두각을 나타내는 RDBMS 중 하나다. 1TB, 3TB, 10TB 등 다양한 데이터 크기 부문에서 HPE, Dell 등 여러 하드웨어 벤더와 협력하여 최상위권 성능 결과를 다수 등재했다.69 이는 SQL Server 엔진에 깊숙이 통합된 컬럼스토어 인덱스와 배치 모드 실행 엔진이 대규모 데이터 스캔과 집계가 주를 이루는 분석 쿼리 처리에 매우 효과적임을 객관적으로 입증한다.78
• Oracle: Exadata와 같은 데이터베이스 최적화 하드웨어 어플라이언스와 결합했을 때, TPC-H에서도 세계 기록 수준의 성능을 보여준다. 2013년에 발표된 SPARC T5-4 서버 기반의 10TB TPC-H 결과는 당시 경쟁 시스템 대비 2.4배 빠른 성능을 기록했다.79 특히 주목할 점은, 쿼리 성능뿐만 아니라 대용량 데이터 로딩 및 갱신(Refresh Function) 속도에서도 경쟁 시스템을 압도하는 경우가 많다는 것이다. 이는 단순히 쿼리가 빠른 것을 넘어, 데이터 웨어하우스 운영 전반의 효율성이 높음을 의미한다.79
• MySQL (with HeatWave): 표준 MySQL은 OLAP 워크로드에 적합하지 않지만, Oracle이 개발한 인메모리 분석 가속 엔진인 HeatWave를 결합하면 양상이 완전히 달라진다. Oracle이 발표한 TPC-H 및 TPC-DS ‘like’ 벤치마크 결과에 따르면, MySQL HeatWave는 Snowflake, Amazon Redshift, Google BigQuery 등 유수의 클라우드 데이터 웨어하우스 서비스와 대등하거나, 경우에 따라 수 배 더 빠른 성능을 훨씬 저렴한 비용으로 제공한다고 주장한다.80 이는 전통적인 OLTP 데이터베이스인 MySQL이 HTAP(Hybrid Transactional/Analytical Processing) 플랫폼으로 진화할 수 있는 강력한 잠재력을 보여준다.
• PostgreSQL: 공식 TPC-H 결과는 드물지만, 다양한 비공식 테스트와 커뮤니티의 보고에 따르면 PostgreSQL의 분석 쿼리 성능은 매우 뛰어나다. 정교한 비용 기반 옵티마이저, 강력한 병렬 쿼리 실행 능력, 그리고 다양한 고급 인덱싱 기법 덕분에 복잡한 조인과 집계를 효율적으로 처리할 수 있다.76

벤치마크 결과는 각 RDBMS의 아키텍처적 특성이 실제 워크로드에서 어떻게 발현되는지를 보여주는 ’최종 성적표’와 같다. TPC-C에서 Oracle RAC가 보여주는 압도적인 확장성은 V절에서 분석한 Shared-Everything 아키텍처와 Cache Fusion의 실질적인 결과물이다.73 TPC-H에서 SQL Server가 거두는 우수한 성과는 IV절에서 논의한 컬럼스토어 인덱스와 배치 모드 실행의 효율성을 증명한다.69 MySQL HeatWave의 놀라운 TPC-H 성능은 전통적인 OLTP 엔진에 인메모리 분석 엔진을 결합하는 HTAP 아키텍처의 성공 가능성을 보여준다.80 이처럼 벤치마크 수치를 이전에 분석한 아키텍처, 동시성 제어, 인덱싱 전략과 같은 내부 메커니즘과 연결하여 종합적으로 해석하는 것이 중요하다.

또한, 성능 경쟁의 축이 변화하고 있다는 점에 주목해야 한다. 과거에는 OLTP(TPC-C)와 OLAP(TPC-H)가 명확히 구분되었지만, 최근에는 CH-benCHmark와 같이 OLTP 트랜잭션과 OLAP 분석 쿼리를 동시에 실행하는 혼합 워크로드(HTAP) 테스트가 중요해지고 있다.80 Oracle이 발표한 자료에서 MySQL HeatWave가 TPC-C 트랜잭션이 실행되는 와중에 CH-benCH 분석 쿼리를 처리하는 시나리오에서 Amazon Aurora 대비 수십 배 빠른 성능을 보였다는 결과는 이러한 트렌드를 명확히 보여준다.80 이는 차세대 RDBMS의 성능 평가 기준이 더 이상 ’최고의 트랜잭션 처리 속도’나 ’최고의 분석 쿼리 속도’가 아니라, ’두 가지 상이한 워크로드를 얼마나 서로의 성능 저하 없이 동시에 처리할 수 있는가’로 진화하고 있음을 의미한다.

8. 총 소유 비용(TCO) 및 라이선스 모델: 성능 대 비용의 균형

아무리 뛰어난 성능을 가진 RDBMS라 할지라도, 그 도입과 운영에 따르는 비용이 비즈니스의 예산 범위를 초과한다면 실용적인 선택지가 될 수 없다. 따라서 성능 평가는 반드시 총 소유 비용(Total Cost of Ownership, TCO) 관점에서의 분석과 병행되어야 한다. TCO는 초기 라이선스 비용뿐만 아니라, 연간 유지보수, 하드웨어, 기술 지원, 그리고 내부 운영 인력 비용까지 모두 포함하는 포괄적인 개념이다.

8.1 상용 RDBMS (Oracle, MS SQL Server)

• Oracle:
• 라이선스 모델: Oracle의 라이선스 모델은 복잡하고 비용이 매우 높은 것으로 알려져 있다. 라이선스는 주로 서버에 장착된 CPU 코어 수를 기준으로 책정되며, 프로세서 종류에 따라 ’코어 팩터(Core Factor)’가 적용되어 최종 비용이 산정된다. 또는, 데이터베이스에 접근하는 사용자 수를 기준으로 하는 ‘Named User Plus’ 모델도 있다.83 가장 큰 비용 부담 요인은 Enterprise Edition의 핵심적인 고급 기능들, 예를 들어 RAC(Real Application Clusters), Partitioning, Advanced Security 등이 대부분 별도로 구매해야 하는 추가 옵션이라는 점이다.63
• 지원 비용: 연간 기술 지원 및 유지보수 비용은 통상적으로 라이선스 비용의 약 22%에 달하며, 이는 매년 지속적으로 발생하는 상당한 고정 비용이다.
• TCO 관점: 초기 도입 비용과 지속적인 유지보수 비용이 5개 RDBMS 중 가장 높다. 그러나 금융 시스템과 같이 1분 1초의 다운타임이 막대한 금전적 손실로 이어지는 미션 크리티컬 환경에서는, Oracle이 제공하는 최고 수준의 성능, 안정성, 보안, 그리고 통합된 전문 기술 지원의 가치가 높은 TCO를 정당화할 수 있다.85
• MS SQL Server:
• 라이선스 모델: Oracle에 비해 상대적으로 단순하고 투명하며 비용 효율적이라는 평가를 받는다. Enterprise Edition은 코어 기반 라이선스가 기본이며, Standard Edition의 경우 서버 라이선스와 접속하는 사용자 또는 디바이스 수에 따른 CAL(Client Access License) 모델을 선택할 수 있다.17 Always On 가용성 그룹과 같은 핵심 고가용성 기능이 Enterprise Edition 라이선스에 포함되어 있어, 유사한 기능을 구현하기 위해 Oracle에서 여러 옵션을 추가 구매해야 하는 것과 비교하면 비용적 이점이 있다.17
• TCO 관점: 전반적으로 Oracle보다 낮은 TCO를 제공하여 중견 및 중소기업에게 매력적인 선택지가 된다. 특히, 기업이 이미 Windows Server, Active Directory 등 Microsoft 생태계를 기반으로 운영되고 있다면, Azure 클라우드로 이전 시 기존 라이선스를 활용하여 비용을 절감할 수 있는 Azure Hybrid Benefit과 같은 프로그램을 통해 추가적인 비용 이점을 누릴 수 있다.17

8.2 오픈소스 RDBMS (PostgreSQL, MySQL, MariaDB)

• 라이선스 모델: PostgreSQL(PostgreSQL License, MIT와 유사), MySQL(GPL, 상용 라이선스 이중 정책), MariaDB(GPL) 등 모두 소프트웨어 자체에 대한 라이선스 비용은 무료다.85 이는 초기 도입 비용을 획기적으로 낮추는 가장 큰 장점이다.
• TCO 구성 요소: 오픈소스 RDBMS의 TCO는 ’무료’라는 단어 뒤에 숨겨진 비용들을 신중하게 고려해야 한다.
• 기술 지원 비용: 장애 발생 시 신속한 해결, 성능 문제에 대한 전문가 컨설팅, 정기적인 패치 및 보안 업데이트 등을 위해 전문 벤더(예: EDB for PostgreSQL, Percona for MySQL/MariaDB, MariaDB Corporation for MariaDB)로부터 유료 기술 지원 구독을 구매하는 것이 일반적이다. 이 구독 비용이 TCO의 상당 부분을 차지한다.
• 인력 비용: 상용 RDBMS에 비해 문제 해결과 최적화를 위한 내부 엔지니어의 역량 의존도가 높다. 숙련된 오픈소스 DBA나 개발자를 채용하고 유지하는 데 드는 인건비는 중요한 TCO 요소다.86
• 생태계 및 도구 비용: 고가용성 구성, 고급 모니터링, GUI 기반 관리 도구 등 상용 RDBMS에서는 기본적으로 제공되는 기능들을 구현하기 위해 여러 서드파티 또는 오픈소스 도구들을 조합해야 하는 경우가 많다. 이러한 도구들의 도입, 통합, 유지보수에 따른 비용이 발생할 수 있다.88
• TCO 관점: 라이선스 비용이 없는 대신 기술 지원, 인력, 생태계 구성에 따른 비용을 종합적으로 고려해야 한다. 그럼에도 불구하고, 특정 벤더에 종속되지 않는 유연성, 필요에 따라 하드웨어를 자유롭게 선택하고 확장할 수 있는 장점 덕분에, 대부분의 경우 상용 RDBMS보다 현저히 낮은 TCO를 달성할 수 있다.84

8.3 커뮤니티 및 기술 지원 생태계

• Oracle/MS SQL Server: 벤더가 직접 제공하는 공식적이고 체계적인 지원 채널이 중심이다. 문제 발생 시 책임 소재가 명확하며, 계약된 서비스 수준 협약(SLA)에 기반한 예측 가능한 지원을 받을 수 있다.64
• PostgreSQL: 기술적으로 깊이 있고 전문적인 개발자 중심의 커뮤니티가 매우 활발하다. 데이터베이스의 근본 원리에 대한 토론과 SQL 표준 준수를 중시하는 문화가 강하다. EDB와 같은 전문 기업들이 Oracle에 필적하는 수준의 엔터프라이즈급 기술 지원과 Oracle 호환성 솔루션을 제공하며 생태계를 이끌고 있다.3
• MySQL/MariaDB: 전 세계적으로 가장 큰 규모의 사용자 커뮤니티를 보유하고 있어, 특히 웹 개발과 관련된 문제에 대한 해결책이나 튜토리얼을 찾기 용이하다. MySQL은 Oracle이, MariaDB는 MariaDB Foundation과 MariaDB Corporation이 개발과 지원을 주도하며 각자의 생태계를 구축하고 있다.3

라이선스 모델은 단순히 비용 문제를 넘어, 시스템 아키텍처를 제약하는 ’기술적 족쇄’로 작용할 수 있다는 점을 이해하는 것이 중요하다. 예를 들어, Oracle의 복잡한 코어 기반 라이선스는 가상화 환경이나 클라우드에서 비용 예측을 어렵게 만들고, 때로는 비용을 절감하기 위해 CPU 수를 인위적으로 제한하는 등의 비효율적인 아키텍처 설계를 강요하기도 한다.83 RAC와 같은 핵심 확장성 기능이 고가의 추가 옵션이라는 점은, 비용 문제로 인해 기술적으로 최적인 아키텍처를 포기하게 만드는 요인이 될 수 있다. 반면, 라이선스 제약이 없는 오픈소스 RDBMS는 개발, 테스트, 스테이징 환경을 자유롭게 복제하여 구성하고, 마이크로서비스 아키텍처에서 각 서비스마다 독립적인 DB 인스턴스를 할당하는 등의 현대적인 아키텍처 패턴을 비용 부담 없이 채택할 수 있는 기술적 자유도를 제공한다.

또한, ‘무료’ 오픈소스의 실제 TCO는 해당 시스템을 운영하는 ’조직의 기술적 성숙도’에 반비례하는 경향을 보인다. 기술적 역량이 뛰어난 엔지니어 조직은 커뮤니티의 지원과 내부 역량을 활용하여 매우 저렴한 비용으로 고성능 시스템을 구축하고 안정적으로 운영할 수 있다.87 하지만 기술적 성숙도가 낮은 조직에게 오픈소스는 문제 발생 시 신속한 해결이 어려운 ’지원 없는 블랙박스’가 될 수 있으며, 결국 상용 RDBMS보다 더 높은 운영 비용과 기회비용을 지불하게 될 수도 있다. 따라서 오픈소스 RDBMS의 TCO를 평가할 때는 반드시 조직의 기술 역량 수준을 냉정하게 평가하고, 필요한 경우 전문 업체의 유료 기술 지원 비용을 TCO에 현실적으로 반영해야 한다.

마지막으로, Amazon RDS, Azure SQL, Google Cloud SQL과 같은 클라우드 DBaaS(Database as a Service)의 등장은 전통적인 TCO 계산법을 근본적으로 바꾸고 있다. DBaaS는 라이선스, 하드웨어, 설치, 패치, 백업, 고가용성 구성 등 전통적인 TCO의 많은 부분을 예측 가능한 월별 서비스 요금에 통합하여 제공한다. 이는 초기 자본 지출(CAPEX)을 운영 비용(OPEX)으로 전환하고, 데이터베이스 관리의 복잡성을 획기적으로 줄여준다.17 이로 인해 TCO 비교의 초점은 ’라이선스 비용 vs. 인력 비용’의 구도에서 ’DBaaS 서비스 요금 vs. 자체 구축/운영 비용’의 구도로 전환되고 있다.

9. 결론 및 워크로드 기반 전략적 제언

9.1 종합 비교 요약

본 보고서는 5대 주요 RDBMS인 Oracle, MS SQL Server, PostgreSQL, MySQL, MariaDB의 성능을 아키텍처, 동시성 제어, 인덱싱, 확장성, 벤치마크, TCO 등 다차원적인 관점에서 심층 분석하였다. 분석 결과, ’모든 시나리오에서 절대적으로 우월한 RDBMS’는 존재하지 않으며, 각 시스템은 고유한 설계 철학과 기술적 특성을 바탕으로 특정 워크로드와 환경에서 차별화된 강점을 보인다는 점을 확인하였다.

• Oracle은 정교한 메모리/프로세스 구조, Undo 기반 MVCC, RAC를 통한 독보적인 쓰기 확장성을 바탕으로 대규모 미션 크리티컬 OLTP 환경에서 최고의 성능과 안정성을 제공한다. 그러나 이는 높은 라이선스 비용과 운영 복잡성이라는 대가를 요구한다.
• MS SQL Server는 통합된 버퍼 풀, 하이브리드 동시성 제어(RCSI), 그리고 강력한 컬럼스토어 엔진을 통해 OLTP와 OLAP 워크로드 간의 뛰어난 균형을 자랑한다. 특히 Microsoft 생태계와의 긴밀한 통합과 상대적으로 합리적인 TCO는 엔터프라이즈 시장에서 강력한 경쟁력으로 작용한다.
• PostgreSQL은 프로세스 기반의 안정적인 아키텍처, 엄격한 MVCC 구현, 그리고 뛰어난 SQL 표준 준수 및 확장성을 통해 복잡한 데이터 모델과 쿼리 처리에 강점을 보인다. 강력한 오픈소스 생태계의 지원을 받지만, 고가용성 구성과 같은 부분은 외부 도구에 의존해야 하는 복잡성이 있다.
• MySQL/MariaDB는 스레드 기반의 경량 아키텍처와 플러그형 스토리지 엔진을 특징으로 하며, 특히 읽기 중심의 웹 워크로드에서 빠르고 효율적인 성능을 제공한다. MariaDB는 MySQL과의 호환성을 기반으로 ColumnStore와 같은 독자적인 기능을 추가하여 HTAP 영역으로의 확장을 모색하고 있다.

9.2 워크로드 유형별 최적 RDBMS 선정 가이드라인

이러한 분석을 바탕으로, 특정 비즈니스 요구사항과 기술적 환경에 따른 최적의 RDBMS 선정 가이드라인을 다음과 같이 제시한다.

• 대규모 미션 크리티컬 OLTP (금융 거래, 통신 과금, 대규모 ERP):
• 최우선 추천: Oracle (RAC 구성)
• 이유: 수 초의 다운타임도 허용되지 않고, 트랜잭션 처리량의 예측 가능한 수평적 확장이 필수적인 환경. 검증된 안정성과 강력한 보안, 그리고 애플리케이션 수정 없이 투명한 쓰기 확장성을 제공하는 RAC는 대체 불가능한 가치를 제공한다. 높은 TCO는 비즈니스 연속성 보장이라는 더 큰 가치로 상쇄될 수 있다.
• Microsoft 생태계 기반 엔터프라이즈 애플리케이션 (OLTP + BI/리포팅 혼합):
• 최우선 추천: MS SQL Server
• 이유: Windows Server, Active Directory,.NET 프레임워크, Power BI, Azure 등 기존 Microsoft 기술 스택과의 완벽한 통합은 개발 및 운영 효율성을 극대화한다. RCSI 옵션을 통해 높은 OLTP 동시성을 확보하고, 내장된 컬럼스토어 인덱스를 통해 추가적인 ETL 없이 운영 데이터에 대한 실시간 분석 성능을 균형 있게 제공한다.
• 복잡한 데이터 모델 및 데이터 무결성이 최우선인 시스템 (GIS, 연구 데이터, 규제 준수 시스템):
• 최우선 추천: PostgreSQL
• 이유: 사용자 정의 타입, 배열, JSONB 등 풍부한 데이터 타입 지원, 엄격한 ACID 및 SQL 표준 준수는 데이터의 무결성과 장기적인 유지보수성을 보장한다. 강력한 쿼리 옵티마이저와 고급 인덱싱 기능은 복잡한 쿼리를 안정적으로 처리하는 데 유리하다. 활발한 커뮤니티와 성숙한 오픈소스 생태계는 기술적 난관 해결에 도움을 준다.
• 대규모 읽기 중심 웹 서비스 및 신속한 개발이 중요한 스타트업:
• 최우선 추천: MySQL 또는 MariaDB
• 이유: 단순한 구조와 검증된 성능으로 빠른 개발 및 배포가 가능하다. 특히 읽기 요청이 쓰기 요청보다 압도적으로 많은 일반적인 웹 서비스, CMS, 커머스 플랫폼 등에서 비용 효율적인 고성능을 제공한다. 거대한 사용자층 덕분에 관련 자료와 숙련된 개발자를 찾기 용이하다. MySQL과의 호환성이 중요하다면 MariaDB는 추가적인 기능과 성능 개선을 제공하는 매력적인 대안이다.
• 실시간 분석이 결합된 HTAP(Hybrid Transactional/Analytical Processing) 워크로드:
• 신중한 고려 대상: Oracle (In-Memory Column Store), MS SQL Server (Columnstore on Rowstore), MariaDB (ColumnStore Engine), MySQL (HeatWave)
• 이유: 이 영역은 각 벤더가 가장 치열하게 경쟁하며 기술을 발전시키고 있는 분야다. 각 솔루션은 서로 다른 아키텍처(인메모리, 별도 엔진, 하이브리드 인덱스 등)를 통해 HTAP를 구현하므로, 실제 분석 쿼리의 복잡성, 데이터 동기화 지연 허용 범위, 기존 시스템과의 통합성 등을 면밀히 검토하고 BMT(Benchmark Test)를 통해 성능을 직접 검증하는 과정이 필수적이다.

9.3 최종 제언

최적의 RDBMS를 선택하는 것은 단순히 기술적 사양을 비교하는 행위를 넘어선, 비즈니스의 미래를 설계하는 전략적 결정이다. 다음의 원칙들을 최종적으로 제언한다.

1. 전략적 관점에서의 종합적 평가: RDBMS 선택은 기술적 특성뿐만 아니라, 조직의 단기 및 장기 예산, 보유 엔지니어의 기술 스택과 숙련도, 미래의 클라우드 전환 전략, 그리고 특정 벤더에 대한 종속성 정책 등 비즈니스적 요소를 반드시 종합적으로 고려해야 한다.
2. 실증적 검증의 필수성: 특정 기술이나 벤더에 대한 선입견이나 ’팬심’을 경계해야 한다. 가장 중요한 것은 우리 조직의 실제 애플리케이션 워크로드와 데이터를 기반으로 한 개념 증명(PoC, Proof of Concept)과 벤치마크 테스트(BMT)를 수행하여, 각 후보 솔루션의 성능, 안정성, 운영 편의성을 객관적인 데이터로 직접 확인하는 과정이다.
3. 클라우드 DBaaS의 적극적 검토: 클라우드 네이티브 시대에 접어들면서, Amazon RDS, Azure SQL, Google Cloud SQL과 같은 DBaaS(Database as a Service)는 전통적인 자체 구축(On-premise) 모델의 대안이 아닌, 우선적으로 고려해야 할 선택지가 되었다. DBaaS가 제공하는 관리 편의성, 탄력적 확장성, 그리고 구독 기반의 비용 모델이 조직의 비즈니스 민첩성과 TCO에 미치는 긍정적인 영향을 적극적으로 평가하고, 자체 구축 모델과 장단점을 비교하여 최적의 배포 전략을 수립해야 한다.

결론적으로, 성공적인 RDBMS 선택은 끊임없이 변화하는 기술 지형도 위에서 우리 조직의 고유한 좌표를 정확히 파악하고, 그에 맞는 최적의 항로를 설계하는 과정과 같다. 본 보고서가 그 여정을 위한 깊이 있고 신뢰할 수 있는 나침반이 되기를 기대한다.

10. Works cited

1. Oracle Architecture - GeeksforGeeks, accessed October 30, 2025, https://www.geeksforgeeks.org/dbms/oracle-architecture/
2. Comparative Analysis of Oracle and MySQL Databases A Study on Query Execution and Scalability, accessed October 30, 2025, https://dr.lib.iastate.edu/bitstreams/9d32e525-6494-40b0-b0a1-cf841ded162e/download
3. The Best Database Servers: Oracle, SQL Server, MySQL, and PostgreSQL Compared | by Salah eddine El khirani | Data Science Clarity | Medium, accessed October 30, 2025, https://medium.com/data-science-clarity/the-best-database-servers-oracle-sql-server-mysql-and-postgresql-compared-fb2f4be17360
4. SQL Server Architecture - Detailed Explanation - InterviewBit, accessed October 30, 2025, https://www.interviewbit.com/blog/sql-server-architecture/
5. SQL Server vs MySQL vs Postgresql: Which One Is the Best - Jelvix, accessed October 30, 2025, https://jelvix.com/blog/mysql-postgresql-sql-server
6. Comparing SQL Database Technologies: MySQL, MSSQL, PostgreSQL, SQLite, and Oracle SQL. Which one should you use? | by Long John | Medium, accessed October 30, 2025, https://medium.com/@longjohn1337/comparing-sql-database-technologies-mysql-mssql-postgresql-sqlite-and-oracle-sql-95699b9c805e
7. PostgreSQL - System Architecture - GeeksforGeeks, accessed October 30, 2025, https://www.geeksforgeeks.org/postgresql/postgresql-system-architecture/
8. Understanding the PostgreSQL Architecture | Severalnines, accessed October 30, 2025, https://severalnines.com/blog/understanding-postgresql-architecture/
9. Architecture of MySQL - GeeksforGeeks, accessed October 30, 2025, https://www.geeksforgeeks.org/mysql/architecture-of-mysql/
10. PostgreSQL vs MySQL - Difference Between Relational Database Management Systems (RDBMS) - AWS, accessed October 30, 2025, https://aws.amazon.com/compare/the-difference-between-mysql-vs-postgresql/
11. The MariaDB architecture - Packt+ | Advance your knowledge in tech, accessed October 30, 2025, https://www.packtpub.com/en-au/product/mastering-mariadb-9781783981540/chapter/1-dot-understanding-the-essentials-of-mariadb-1/section/the-mariadb-architecture-ch01lvl1sec02
12. PostgreSQL vs MySQL vs MariaDB: Which Database Fits Your Needs?, accessed October 30, 2025, https://www.opensourceforu.com/2025/09/postgresql-vs-mysql-vs-mariadb-which-database-fits-your-needs/
13. MariaDB vs MySQL: The Ultimate Comparison - DbVisualizer, accessed October 30, 2025, https://www.dbvis.com/thetable/mariadb-vs-mysql-the-ultimate-comparison/
14. Oracle Database Technical Architecture, accessed October 30, 2025, https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/database-technical-architecture.html
15. An Overview of Oracle Database Architecture, accessed October 30, 2025, https://www.oracletutorial.com/oracle-administration/oracle-database-architecture/
16. Understanding Oracle Database Architecture: A Beginner’s Guide to the Core Components, accessed October 30, 2025, https://medium.com/@ibukunjeje/understanding-oracle-database-architecture-a-beginners-guide-to-the-core-components-69005e5c6952
17. Oracle vs SQL Server: Key Differences for Modern Data Teams | Estuary, accessed October 30, 2025, https://estuary.dev/blog/oracle-vs-sql-server/
18. SQL Server Architecture Explained: What is SQL Server & Its Components? | Simplilearn, accessed October 30, 2025, https://www.simplilearn.com/what-is-microsoft-sql-server-architecture-article
19. MySQL Architecture, accessed October 30, 2025, https://www.mysqltutorial.org/mysql-administration/mysql-architecture/
20. Oracle Database 19c Technical Architecture, accessed October 30, 2025, https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/pdf/db-19c-architecture.pdf
21. Understanding the Fundamentals of PostgreSQL® Architecture - NetApp Instaclustr, accessed October 30, 2025, https://www.instaclustr.com/blog/postgresql-architecture/
22. Documentation: 18: 1.2. Architectural Fundamentals - PostgreSQL, accessed October 30, 2025, https://www.postgresql.org/docs/current/tutorial-arch.html
23. Introduction to Oracle Database, accessed October 30, 2025, https://docs.oracle.com/en/database/oracle/oracle-database/18/cncpt/introduction-to-oracle-database.html
24. MS SQL Server - Architecture - Tutorials Point, accessed October 30, 2025, https://www.tutorialspoint.com/ms_sql_server/ms_sql_server_architecture.htm
25. Microsoft SQL Server - Wikipedia, accessed October 30, 2025, https://en.wikipedia.org/wiki/Microsoft_SQL_Server
26. Understanding MariaDB Architecture, accessed October 30, 2025, https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/migrating-to-mariadb-from-sql-server/understanding-mariadb-architecture
27. MariaDB vs. PostgreSQL, accessed October 30, 2025, https://mariadb.com/products/enterprise/comparison/mariadb-vs-postgresql/
28. MariaDB vs PostgreSQL - Difference Between Open-Source Relational Databases - AWS, accessed October 30, 2025, https://aws.amazon.com/compare/the-difference-between-mariadb-and-postgresql/
29. Multiversion Concurrency Control (MVCC) – A Deep Dive Part (1/2) - DEV Community, accessed October 30, 2025, https://dev.to/fashadahmed/multiversion-concurrency-control-mvcc-a-deep-dive-part-12-18a5
30. Multiversion concurrency control - Wikipedia, accessed October 30, 2025, https://en.wikipedia.org/wiki/Multiversion_concurrency_control
31. What is Multiversion Concurrency Control (MVCC) and who supports it? - Stack Overflow, accessed October 30, 2025, https://stackoverflow.com/questions/27499/what-is-multiversion-concurrency-control-mvcc-and-who-supports-it
32. Multiversion Concurrency Control (MVCC): A Practical Deep Dive - CelerData, accessed October 30, 2025, https://celerdata.com/glossary/multiversion-concurrency-control
33. Comparing Data Stores for PostgreSQL - MVCC vs InnoDB …, accessed October 30, 2025, https://severalnines.com/blog/comparing-data-stores-postgresql-mvcc-vs-innodb/
34. Well-known Databases Use Different Approaches for MVCC - EDB Postgres AI, accessed October 30, 2025, https://www.enterprisedb.com/blog/well-known-databases-use-different-approaches-mvcc
35. Understanding Concurrency Control in SQL Server and PostgreSQL …, accessed October 30, 2025, https://www.sqlpassion.at/archive/2025/01/16/understanding-concurrency-control-in-sql-server-and-postgresql-a-comparative-analysis/
36. What are the tradeoffs between Postgresql’s and Oracle’s implementation of MVCC?, accessed October 30, 2025, https://www.reddit.com/r/PostgreSQL/comments/te9za5/what_are_the_tradeoffs_between_postgresqls_and/
37. Understanding Concurrency Control: 2PL vs. MVCC in Database Systems - Stackademic, accessed October 30, 2025, https://blog.stackademic.com/understanding-concurrency-control-2pl-vs-mvcc-in-database-systems-2e8af23f1668
38. Difference Between Indexing Techniques in DBMS - GeeksforGeeks, accessed October 30, 2025, https://www.geeksforgeeks.org/dbms/difference-between-indexing-techniques-in-dbms/
39. Database Indexing Demystified – B-Tree vs Hash vs Bitmap - Design Gurus, accessed October 30, 2025, https://www.designgurus.io/blog/database-index-hash-vs-tree-vs-bitmap
40. Index Architecture and Design Guide - SQL Server - Microsoft Learn, accessed October 30, 2025, https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver17
41. B-Tree vs Bitmap database indexes - Stack Overflow, accessed October 30, 2025, https://stackoverflow.com/questions/9541541/b-tree-vs-bitmap-database-indexes
42. Bitmap Index vs. B-tree Index: Which and When? - Oracle, accessed October 30, 2025, https://www.oracle.com/technical-resources/articles/sharma-indexes.html
43. What Are the Types of Indexes in a Relational Database? - Redgate Software, accessed October 30, 2025, https://www.red-gate.com/blog/database-index-types
44. Query Processing Architecture Guide - SQL Server | Microsoft Learn, accessed October 30, 2025, https://learn.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver17
45. Real Applications Clusters | Oracle, accessed October 30, 2025, https://www.oracle.com/database/real-application-clusters/
46. What is Oracle RAC and Why Use it for Scaling Workloads? - Redgate Software, accessed October 30, 2025, https://www.red-gate.com/simple-talk/featured/what-is-oracle-rac-and-why-use-it-for-scaling-workloads/
47. Oracle Real Application Clusters (RAC) on Oracle Database 19c, accessed October 30, 2025, https://www.oracle.com/technetwork/database/options/clustering/rac-twp-overview-5303704.pdf
48. Mastering Oracle RAC: Your Guide to High Availability and Scalability - Surety Systems, accessed October 30, 2025, https://www.suretysystems.com/insights/mastering-oracle-rac-your-guide-to-high-availability-and-scalability/
49. What is an Always On availability group? - SQL Server Always On …, accessed October 30, 2025, https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver17
50. Always On Availability Groups vs. Failover Cluster Instances - StarWind, accessed October 30, 2025, https://www.starwindsoftware.com/blog/always-on-availability-groups-vs-failover-cluster/
51. Configure SQL Server Always On availability groups with synchronous commit using an internal load balancer | Compute Engine | Google Cloud Documentation, accessed October 30, 2025, https://docs.cloud.google.com/compute/docs/instances/sql-server/configure-availability
52. What is SQL Server AlwaysOn Availability Group? - Boltic, accessed October 30, 2025, https://www.boltic.io/blog/always-on-sql-server
53. AlwaysOn Availability Groups: Step by Step Setup Tutorials - Brent Ozar Unlimited, accessed October 30, 2025, https://www.brentozar.com/sql/sql-server-alwayson-availability-groups/
54. PostgreSQL® high availability: Methods, topologies and tips, accessed October 30, 2025, https://www.instaclustr.com/education/postgresql/postgresql-high-availability-methods-topologies-and-tips/
55. Achieving and Maintaining High Availability in PostgreSQL - EDB, accessed October 30, 2025, https://www.enterprisedb.com/achieving-maintaining-high-availability-postgresql
56. PostgreSQL High Availability Options: A Guide - Yugabyte, accessed October 30, 2025, https://www.yugabyte.com/postgresql/postgresql-high-availability/
57. Chapter 26. High Availability, Load Balancing, and Replication - PostgreSQL, accessed October 30, 2025, https://www.postgresql.org/docs/current/high-availability.html
58. A Comparison of High Availability PostgreSQL Solutions | Linode Docs, accessed October 30, 2025, https://www.linode.com/docs/guides/comparison-of-high-availability-postgresql-solutions/
59. The MySQL High Availability Landscape and where Galera Cluster …, accessed October 30, 2025, https://galeracluster.com/videos/the-mysql-high-availability-landscape-and-where-galera-cluster-fits-in/
60. PostgreSQL Architecture Explained | Yugabyte, accessed October 30, 2025, https://www.yugabyte.com/postgresql/postgresql-architecture/
61. PostgreSQL vs MySQL vs MariaDB: Complete Database Comparison for Modern Applications | Better Stack Community, accessed October 30, 2025, https://betterstack.com/community/comparisons/postgresql-vs-mysql-vs-mariadb/
62. Mysql vs Oracle XE vs Postgresql . Scalability and performance, which to chose? [closed], accessed October 30, 2025, https://stackoverflow.com/questions/13952182/mysql-vs-oracle-xe-vs-postgresql-scalability-and-performance-which-to-chose
63. Oracle vs SQL Server 2025: Features, Performance & Licensing Guide - CADD Centre, accessed October 30, 2025, https://caddcentre.com/blog/oracle-vs-sql-server-features-performance-licensing-explained-for-2025/
64. Oracle vs. SQL Server: Comprehensive Database Comparison - Futuramo, accessed October 30, 2025, https://futuramo.com/blog/oracle-vs-sql-server-head-to-head-comparison/
65. PostgreSQL vs SQL Server: What are the key differences? - Google Cloud, accessed October 30, 2025, https://cloud.google.com/learn/postgresql-vs-sql
66. TPC-C Homepage - TPC.org, accessed October 30, 2025, https://www.tpc.org/tpcc/
67. TPC-H Homepage - TPC.org, accessed October 30, 2025, https://www.tpc.org/tpch/
68. TPC-C - Wikipedia, accessed October 30, 2025, https://en.wikipedia.org/wiki/TPC-C
69. TPC-H Perf, accessed October 30, 2025, https://www.tpc.org/tpch/results/tpch_perf_results5.asp
70. SQL Server Performance - Nutanix Support Portal, accessed October 30, 2025, https://portal.nutanix.com/page/documents/solutions/details?targetId=TN-2172-NC2-in-Microsoft-Azure-for-Database-Workloads:sql-server-performance.html
71. TPCC-Like Workload for Sysbench 1.0 - Percona, accessed October 30, 2025, https://www.percona.com/blog/tpcc-like-workload-sysbench-1-0/
72. MySQL Performance : 8.0 GA and TPCC Workloads | DimitriK’s (dim) Weblog - Free, accessed October 30, 2025, http://dimitrik.free.fr/blog/posts/mysql-performance-80-ga-and-tpcc-workloads.html
73. ORACLE REAL APPLICATION CLUSTERS (RAC), accessed October 30, 2025, https://www.oracle.com/partners/campaign/022243.pdf
74. Running TPC-C on MySQL/RDS - High Scalability -, accessed October 30, 2025, https://highscalability.com/running-tpc-c-on-mysqlrds/
75. Benchmark OLTP performance on AlloyDB for PostgreSQL - Google Cloud Documentation, accessed October 30, 2025, https://docs.cloud.google.com/alloydb/docs/benchmark-oltp-performance-alloydb
76. Vonng/pgtpc: TPC B/C/H Benchmark for PostgreSQL - GitHub, accessed October 30, 2025, https://github.com/Vonng/pgtpc
77. These Microsoft SQL Server on RHEL 8 benchmark results might surprise you - Red Hat, accessed October 30, 2025, https://www.redhat.com/en/blog/these-microsoft-sql-server-benchmark-results-might-surprise-you
78. Microsoft SQL Server Benchmarks and Performance | SoftSolutionWorks.com, accessed October 30, 2025, https://www.softsolutionworks.com/sqlserverbbenchperform.asp
79. World Record Single System TPC-H @10000GB Benchmark on SPARC T5-4 - Oracle Blogs, accessed October 30, 2025, https://blogs.oracle.com/oracle-systems/post/world-record-single-system-tpc-h-10000gb-benchmark-on-sparc-t5-4
80. HeatWave Performance Benchmark | Oracle, accessed October 30, 2025, https://www.oracle.com/heatwave/performance-benchmarks/
81. tvondra/pg_tpch: TPC-H like benchmark for PostgreSQL - GitHub, accessed October 30, 2025, https://github.com/tvondra/pg_tpch
82. Benchmark Report - Apache Amoro™, accessed October 30, 2025, https://amoro.apache.org/benchmark-report/
83. Oracle vs SQL Server - Key Differences | Airbyte, accessed October 30, 2025, https://airbyte.com/data-engineering-resources/oracle-vs-sql-server
84. PostgreSQL Vs. Oracle: Costs, Ease Of Use & Functionality - ScaleGrid, accessed October 30, 2025, https://scalegrid.io/blog/postgresql-vs-oracle-difference-in-costs-ease-of-use-functionality/
85. Oracle vs. PostgreSQL: Key Differences and Best Use Cases - EDB, accessed October 30, 2025, https://www.enterprisedb.com/blog/oracle-vs-postgresql-comparison
86. MS SQL Server, MySQL , Oracle DBA, PostgreSQL - Which is good, which to start learning - Reddit, accessed October 30, 2025, https://www.reddit.com/r/SQL/comments/spxzfh/ms_sql_server_mysql_oracle_dba_postgresql_which/
87. Top 10 open source databases: Detailed feature comparison - NetApp Instaclustr, accessed October 30, 2025, https://www.instaclustr.com/education/managed-database/top-10-open-source-databases-detailed-feature-comparison/
88. MariaDB vs PostgreSQL: 14 Critical Differences - Kinsta, accessed October 30, 2025, https://kinsta.com/blog/mariadb-vs-postgresql/
89. Microsoft vs Oracle 2025 | Gartner Peer Insights, accessed October 30, 2025, https://www.gartner.com/reviews/market/data-integration-tools/compare/microsoft-vs-oracle
90. Support for Oracle Database@Azure | Microsoft Learn, accessed October 30, 2025, https://learn.microsoft.com/en-us/azure/oracle/oracle-db/oracle-database-support
91. PostgreSQL vs MySQL - UpGuard, accessed October 30, 2025, https://www.upguard.com/blog/postgresql-vs-mysql
92. PostgreSQL vs MySQL: The Critical Differences - Integrate.io, accessed October 30, 2025, https://www.integrate.io/blog/postgresql-vs-mysql-which-one-is-better-for-your-use-case/